nanoFlash Public Beta 1.6.226 Firmware Comments

[Piotr Wozniacki]

Dear Dan, Peter, Rafael and Billy,

I'm of course following your posts on the Aperture setting in QT files with great interest, but - having no access to Mac/full QT player / FCP, and only working with MXF - I cannot help much. Has anyone found any information about using a similar setting in MXF files?

That said, I still believe the differences in scopes I posted are mainly due to the 420 vs. 422 color subsampling.

Cheers

Piotr

[Piotr Wozniacki]

As one of those who changed the subject of this thread, I'd like to repeat my kind request to Chris to move the posts, related to the Aperture subject, into a new thread of its own.

Coming back to the current Beta discussion, I'd like to say that - to my very positive surprise - I have discovered that my Transcend 400X, 64GB cards now work with 280 Mbps bitrate!

Dan, if CD has improvement on the nanoFlash performance again - then all I can say is WOW, thank you :)

Piotr

PS. Please answer my question about the slight audio lag, though....

[Dan Keaton]

Dear Piotr,

Please be careful in testing for 280 Mbps.

Please record a test until the card completely fills up.

We have a huge buffer in the nanoFlash. A slower card will appear to work at a higher speed due to this buffer, but, over-time, our buffer will fill up, and we will have to down-shift to a slower bit-rate.

(And most any card will work at 280 Mbps if one is doing a time-lapse sequence.)


For the audio delay, could you run a test for us?


Record internally, and record to the nanoFlash.

Have a clapper or other similar device, very close to the lens and microphone.

Test, in post if the audio and video are aligned.

Test using Sony Vegas Pro 10.

Then check the footage in Sony Clip View 2.30.

Then test the nanoFlash clips.

I am will say that it would be possible for the nanoFlash to be 0.004 seconds off..

Before we run the audio alignment tests, I will need to know the details when you noticed that they were 0.004 seconds off. What Frame Rate, Embedded or Analog Audio Input, specific camera, how far the sound was from the Mike, etc.?

[Rafael Amador]

Dear Dan and all,

APERTURE:
I've been playing with the "Aperture" on different NANO's and SxS clips(1920x1080 and 1280x720).
I can't say more than: The more I play, the most confused I get.
I don't know if I'm making something wrong or QT Player is behaving in an erratic and unexpected way.
In short: Applying the same aperture to the same clip, not always shows the same picture. Changing modes, some times the picture shows four different "aspects". Some times I shift modes and I get only two "aspects". Some times, no change.
it seems that the 4 modes shows the same. Then, I have to close the picture and open again to make functional the "Aperture" control.
So, sorry, but nothing clear.
So two options:
- Let things as they are.
- Change mode. In this case I think the best option I think should be "Encoded Pixels".
As the Apple says:
"Encoded Pixels: Neither crops nor scales the video. A DV NTSC (4:3 or 16:9) track appears as 720 x 480.
With HDTV formats, we have nothing to correct. We know that we have 1920x1080 or 1280x720 Square pixels.
Thats exactly what we have to display: FULL/PLAIN HD.

PIOTR's Test
SxS and NANO picture compared on the Vegas VideoScope;
The same difference that shows Vegas, is shown by FC.
But I do not consider the differences on the Waveform neither on the Vectorscope. I think that the differences on Waveform and Vectorscope is understandable and is due to the 422 vs 420 compression.
The difference to consider is on the Histogram.
For me here is the problem.
What is what should show a Histogram?
The Waveform shows Luma and the measure unity are IRE.
The Vectorscope shows the phase of the Color Components, and the resulting Chroma Vector.
But, what should show the Histogram?
What measures make?
Which unities uses?
Well, the Histogram doesn't really measure nothing.
Is an spatial representation of the Luma values of the whole picture (some systems/software have also RGB Histograma).
The Histogram try to give a visual idea of the main "luma bands' (?) on the picture.
You need accuracy on a Waveform and on a Vectorscope because otherwise you are at risk of going "illegal", but YOU REALLY DON'T NEED MUCH ACCURACY ON A HISTOGRAM.
Those little differences doesn't change nothing for the Video Editor/Colorist.
So I think that the differences may be due to the no much exigent design of the filter.

So take the Histogram for what is intended: A rough visual representation.

Make a test:
Transcode your SxS and your NANO clip to any 8b and 10b Uncompress format and compare their Histograms.
You will find that the 6 clips shows 6 different Histograms.
No much concern about that anyway.
Cheers,
rafael

[Piotr Wozniacki]

Originally Posted by Dan Keaton

We have a huge buffer in the nanoFlash. A slower card will appear to work at a higher speed due to this buffer, but, over-time, our buffer will fill up, and we will have to down-shift to a slower bit-rate.

Dear Dan,

I'm aware of the buffer, but with previous firmware, it filled up and the nano down-shifted pretty quick when recording 1080/25p I-Fo at 280 Mbps.

Now, of course I didn't have time or patience to fill up entire card, but I recorded more than 5 mins video is several files. It never down-shifted!

As to the audio lag, the picture below shows waveforms of the nano (upper) and native (bottom) clips, recorded simultaneously on the EX1, with the nano fed from SDI. They have been aligned on Vegas timeline using single video frame accuracy. The ruler is scaled in seconds. I really don't know what else I can say.

Thanks,

Piotr

[Dan Keaton]

Dear Piotr,

To prove that the 280 Mbps will actually work for you, for long takes, you will need to fill up the card.

You can also use one of our new features to "see inside" the nanoFlash.

We now have a FIFO level display. FIFO is the First In, First Out buffer.

The lower the percent of the FIFO that we are using the better.

If the FIFO creeps up and then goes back down, then this is normal.

If it jumps up then stays up, the the card is too slow for the Bit-Rate in use.

The following is from our latest manual 1.6.226.

Fifo Meter Display:

Displays the CF card's ability to keep up with the data rate of the video.

From the main menu, press and hold the left arrow key, and then press record button to initiate
a record session.

If Fifo meter rises over time towards 100%, the CF card is too slow to
handle the data rate. (Small spikes in the meter will appear during file transitions.)


As far as the audio, I see that the audio is different by 4 ms.

Which one is closest to being in-sync with the video?

How far away from the mic is the sound source?

In dry air at 20 °C (68 °F), the speed of sound is 343.2 metres per second (1126 ft/s). (Wikipedia)

Thus 0.004 seconds is about 4.5 feet away or 1.372 meters. (Dan)

[Rafael Amador]

Originally Posted by Dan Keaton

Dear Piotr,

We have a huge buffer in the nanoFlash. A slower card will appear to work at a higher speed due to this buffer, but, over-time, our buffer will fill up, and we will have to down-shift to a slower bit-rate.

Dear Dan,
Just for curiosity, how big is the buffer?
rafael

[Peter Moretti]

Originally Posted by Dan Keaton

...
As far as the audio, I see that the audio is different by 4 ms.

Which one is closest to being in-sync with the video?

How far away from the mic is the sound source?

In dry air at 20 °C (68 °F), the speed of sound is 343.2 metres per second (1126 ft/s). (Wikipedia)

Thus 0.004 seconds is about 4.5 feet away or 1.372 meters. (Dan)

Sorry to jump into this, but I had mentioned mic distance to Piotr, and he responded that:

1) The EX and nano were recording sound simultaneously from the same mic, so any delay caused by distance should be the same for both.

2) He never experienced this delay until this new firmware upgrade.

(I hope I characterized his responses correctly.)

Okay, I'll leave ya'll alone now :).


-Peter

[Dan Keaton]

Dear Peter,

Thank you.

1. Yes, that makes perfect sense, same distance for both.

I did the calculations to show how critical the distance is, even a short distance, for getting the audio and video synced.

2. That may be true also, but did Piotr run these tests earlier?

Of course we want to get the audio/video sync dead on.

But, a lot goes into this. A lot also goes into the camera to get the audio and video syned up also.

We do not know, for a fact, if the audio and video are perfectly lined up in the internal recording, and if this exactly matches the HD-SDI out. It may be, and I would expect it to be, but we have to consider this possibility.


Also, I am attempting to envison a reason, if one is recording to an EX camera, and to the nanoFlash simultaneously, why one needs to intercut footage from the EX with the nanoFlash footage.

But, as I said, I want to get this audio / video sync as close as possible.

Right now, .004 seconds, or 1/250th of a second is pretty close, but not perfect.

The Vegas Timeline Piotr has posted has been zoomed in greatly to show this offset.

[Piotr Wozniacki]

Originally Posted by Dan Keaton

Also, I am attempting to envison a reason, if one is recording to an EX camera, and to the nanoFlash simultaneously, why one needs to intercut footage from the EX with the nanoFlash footage.

Dear Dan,

In the type of recording I mentioned earlier in this thread, I usually shoot the live classical music performances with 3 cameras (EX1's). In the ideal world, they all should be recording to nanoFlashes - but unfortunately, I only have one. So I'm using it with the main camera, and the nanoFlash files get intercut with the native XDCAM EX from the other two (I know it's not a good scenario, but at least I have some material of the highest quality possible).

So, as you can realize, it's of paramount importance that for multi-camera edits, I can be sure all images are in the same position in time in relation to the sound (which is BTW recorded separately, the on-camera sound being only used for reference during editing).

You could say now that the offset can be greater due to the cameras being located in different distances from where the microphones are, and you'll be right - but the human brain is very smart, and when watching a musician from some distance, it allows for slight delay in sound. On the other hand, no delay whatsoever is tolerated for close-ups - and when I show them from 2 or 3 different angles, I must do this tedious sound slipping by milliseconds, in order to get it right....

Piotr

[Piotr Wozniacki]

Originally Posted by Rafael Amador

Dear Dan,
Just for curiosity, how big is the buffer?
rafael

I second this question, Dan - right now recording at 280 Mbps on my Transcend 400X card, and the buffer only filled up to some 30% at the beginning, but now is at no more than 10%...

So, could it be true that with the new firmware, the Transcend cards are fully capable of 280 Mbps?

Piotr

PS. Still recording at 280, and the buffer bar is barely above 0%!

[Russell Heaton]

Call me stupid, but looking at Piotr's Vegas timeline, the larger increments on his scale are 0.002 seconds and the smaller divisions are 0.0002 seconds. So it looks to me that any delay might be in the order of 0.0001 seconds because, to me, that's all the shift between the waveforms appears to be.

Put another way, that's about 100 microseconds. I can't believe it is even being considered a problem, unless it is cumulative. If it is constant then who cares? I defy anyone to hear that delay in a real-world application.

Cheers

Russ

[Piotr Wozniacki]

Originally Posted by Russell Heaton

Call me stupid, but looking at Piotr's Vegas timeline, the larger increments on his scale are 0.002 seconds and the smaller divisions are 0.0002 seconds. So it looks to me that any delay might be in the order of 0.0001 seconds because, to me, that's all the shift between the waveforms appears to be.

Put another way, that's about 100 microseconds. I can't believe it is even being considered a problem, unless it is cumulative. If it is constant then who cares? I defy anyone to hear that delay in a real-world application.

Cheers

Russ

Russ,

It's exactly 0.004 sec - please compare the length of the selection bar with the distance on the ruler, between the 22,370 and 22,374 stops...

[Dan Keaton]

Originally Posted by Rafael Amador

Dear Dan,
Just for curiosity, how big is the buffer?
rafael

Dear Rafael and Piotr,

It is very large, but I consider the size to be a trade secret.


Dear Rafael,

Our recommended bit-rates have to be conservative.

Not all cards, of a certain brand/type perform exactly the same.

And cards get busy, at times.

If 280 Mbps, with your Transcend 400x 64 GB cards works, then great.

And I have no problem with others testing their cards.

Just remember, I recommend taking the time to record until the card is full during the test.

As everyone should be aware, we have a program to constantly refine the firmware in the nanoFlash.

[Piotr Wozniacki]

Originally Posted by Dan Keaton

Our recommended bit-rates have to be conservative.

Dear Dan,

While I understand the above statement, just a technical question: if the buffer shows less than 10% after some 5 mins recording, and stays this way - is there still a chance it would overflow? If so, what could ever cause it?

Of course, if I ever use my cards at 280 Mbps in production, is my own responsibility.

Piotr