Sony FS100 AVCHD holds better in color grading than anything else

Can't Avid MC ingest AVCHD now? I thought it could ? I thought it converts to DNxHD

Well, Avid claims MC will do AVCHD. It won't do it in AMA(fast import) mode, and there's a bug in the standard import code.
What front end GUI are you using with FFMPEG?
 
Well, Avid claims MC will do AVCHD. It won't do it in AMA(fast import) mode, and there's a bug in the standard import code.
What front end GUI are you using with FFMPEG?

I don't use a GUI, I use it in a batch file

BTW, FFMPEG can't do the 10bit variety of DNxHD, only 8-bit .

So you're looking for a alternate batch methods of converting to DNxHD ?
 
Oh but there is - DS imports / captures /exports full range (0-1023) if you ask it too...

Currently i'm finishing a feature shot on 16mm, xfered Dmin/Dmax on a Sprit so the HDSR tape is full range, and after i have it finished (three reels done now, two more to go) I'm exporting full range DXP (0-1023) for filmout on a ArriLazer

It's done all the time.. really... and just about every DI tool set on the planet can do it

d


Sorry what program is DS ? We're talking about BM v210 here , correct ? That's what my comments were specifically referring to in reponse to Frank's question about his BM YUV 10bit results

Of course there are formats and workflows that can store full range 10-bit YUV ...
 
Last edited:
So you're looking for a alternate batch methods of converting to DNxHD ?

yep.....so I don't tie up my Avid doing transcoding. I can batch the conversions on another machine.
 
So you're looking for a alternate batch methods of converting to DNxHD ?

yep.....so I don't tie up my Avid doing transcoding. I can batch the conversions on another machine.


FFMPEG can only do the 8bit variety of DNxHD, not sure if you want/like v210, the filesizes are huge compared to DNxHD.

I dislike DNxHD because MOV container causes so many issues with different programs, gamma problems, levels shifts

If you are on a PC, DNxHD is usually routed through quicktime. Big headache.
 
Sorry what program is DS ? We're talking about BM v210 here , correct ? That's what my comments were specifically referring to in reponse to Frank's question about his BM YUV 10bit results

Of course there are formats and workflows that can store full range 10-bit YUV ...
DS = Avid DS = Avid's 4K/2k/HD finishing system;
http://www.avid.com/US/products/dssoftware

I don't use BMD's codecs, and i don't use Cineform codec's either.. neither of them are a match for my workflow.

I have no problems round tripping with 10bit DNxHD, they seem fine for broadcast use, i don't use any codec's for filmout or DCP projects, they stay uncompressed, even if shot on a FS100

back to Frank's issues.. seems more about his workflow than about the strength of the native h.264 codec the camera shoots in... and to say h.264 better than ANYTHING is perhaps overstating it a bit?

d/



\
 
FFMPEG can only do the 8bit variety of DNxHD, not sure if you want/like v210, the filesizes are huge compared to DNxHD.

I dislike DNxHD because MOV container causes so many issues with different programs, gamma problems, levels shifts

If you are on a PC, DNxHD is usually routed through quicktime. Big headache.
MetaFuze is free man... what more can you ask for?

re-wrap to h.264
use MetaFuze to make MXF media & ALE from the h.264's
copy MXF media into an indexed directory
open ALE in Avid
done like dirt, get to work....

d
 
Metafuze? Sorry, but the last time I looked, Metafuze can only do 24fps. Has it been updated?
edit: ok, I checked Metafuze out. It seems it will do a whole range of formats...totally cool!
Unfortunately, a scan of my folders and Metafuze won't recognize my Nanoflash XDCAM 422 files(mpeg2 in a mxf wrapper)
 
Last edited:
Thanks for you input guys.

I was always under the impression that converting to a „higher“ codec – especially an uncompressed one – would (of course) not make the image better or ad information out of nothing, but would at least not loose information.

It looks like I was wrong and the YUV-RGB conversions probably also have something to do with it.

Well, that only strengthens my believe in an uncompressed workflow from recording till delivery.

I gonna do some tests - AVCHD in camera vs. uncompressed Hypershuttle tomorrow and see what I can get.

Frank
 
Hey PDR - this is somewhat related to this thread.

When I create a pure computer graphic with a smooth gradient (in RGB space), and then render it to video, I always get very noticable banding. It's clearly a color space conversion issue. It doesn't matter what codec I render to, it doesn't matter if it's 422 or 420, it's always there. Do you have any thoughts on how to deal with this?
 
Hey PDR - this is somewhat related to this thread.

When I create a pure computer graphic with a smooth gradient (in RGB space), and then render it to video, I always get very noticable banding. It's clearly a color space conversion issue. It doesn't matter what codec I render to, it doesn't matter if it's 422 or 420, it's always there. Do you have any thoughts on how to deal with this?
If you're working in 8-bit color depth, chances are it's because of the round off errors with 8-bit color. That's the reason for moving to a 10-bit workflow.
 
Hey PDR - this is somewhat related to this thread.

When I create a pure computer graphic with a smooth gradient (in RGB space), and then render it to video, I always get very noticable banding. It's clearly a color space conversion issue. It doesn't matter what codec I render to, it doesn't matter if it's 422 or 420, it's always there. Do you have any thoughts on how to deal with this?

If there is no banding even in an 8-bit RGB format, it's likely going from to RGB to "legal range" 8-bit YUV (Y' 16-235 ,and 16-240 for CbCr) . Since there is less range of expression (black to white only goes from 16-235 instead of 0-255 in RGB), banding is worse . Working at higher bit depth for intermediate calculations as cuervo suggested above will help, but ultimately going to a 8-bit YUV delivery format will cause banding in gradients, especially computer generated ones


Do you recall our discussion about full range YUV flash vs. limited range, where if you control the implementation, the banding greatly improves?

(i.e. you control the conversion back to RGB for display using full range Y'CbCr [0,255] => RGB [0,255] using the full range flag - something you cannot do with vimeo, youtube, but you can with your own website) . Of course , this isn't something you can do with say blu-ray or dvd if those are your destination formats

In practical sense for common delivery formats (DVD, blu-ray), most people dither or add noise to the content . This is very hard on compression, but if you use ordered dithering, it's easier on the compression. Also dithering through masks (it's applied selectively only to areas that need it)
 
Last edited:
but ultimately going to a 8-bit YUV delivery format will cause banding in gradients, especially computer generated ones.
This is exactly the problem. Am I wrong, but it doesn't appear that a 10 bit workflow or going RGB lossless through post will save you from this ultimate day of reckoning.

In practical sense for common delivery formats (DVD, blu-ray), most people dither or add noise to the content . This is very hard on compression, but if you use ordered dithering, it's easier on the compression. Also dithering through masks (it's applied selectively only to areas that need it)
Ordered dithering? Dithering through masks? This is all new to me. Can you elaborate.
 
This is exactly the problem. Am I wrong, but it doesn't appear that a 10 bit workflow or going RGB lossless through post will save you from this ultimate day of reckoning.

It does help to prevent/introduce new banding. Higher bit depth effects and higher precision, less rounding errors . This is easily demonstratable, the difference between working at higher bit depth and lower bit depth with things like ramps, gradients


Ordered dithering? Dithering through masks? This is all new to me. Can you elaborate.

Dithering is essentially noise that hide the banding

http://en.wikipedia.org/wiki/Dither#Digital_photography_and_image_processing
http://en.wikipedia.org/wiki/Ordered_dithering

Ordered dithering is preferred (compression wise), because of long GOP compression. In common delivery formats, long GOP compression is used to store differences between frames . Instead of "random" patterns, there is a more defined pattern, which ends up consuming less bitrate because there are less difference between frames with respect to the noise pattern (so more bitrate gets allocated to the image you're trying to show, rather than wasted on dithering)

There are some 3rd party plugins e.g .Genarts Sapphire has one called deband , I'm sure there are a few others

Of course, avisynth has quite a few, the "Gradfun" family (eg. gradfun2dbmod, gradfun3), dither, flash3kyuu, a few others
 
This is a curious discussion. Things are rarely as they seem on the surface. Things, in this case, really depend on the logic of the compression algorithm. Take for example, the Sony MPED2 HD codec. Once the bitrate is selected, it is the limiting factor. If the level of detail goes up in the image frame, the codec spends more time compressing the data to keep the bitrate you selected. If there is motion in the frame, the codec does the same thing. Increasing detail and increasing full frame motion stress the bandwidth limit of the codec. The more stress, the more quantization artifacts you're gonna see.

Adding noise is a curious phenomenon. The grain introduced with noise appears to the compression routine like increasing detail. So, at some point, adding noise begins to affect the blocking artifacts while reducing the stairrstepping. It's all a curious game of balancing competing evils.....LOL
 
And when you encode to h264, it will increase the banding more as it compresses the 8-bits even more down. The only real way to combat this is to add noise. And then you upload it to vimeo which will encode it again and thus increasing banding again! Yay
 
Back
Top