ffmpeg & final cut pro best format question

[David Favor]

Someone let me know the command line for converting
.mts AVCHD files to a format Final Cut Pro can ingest
and use without re-rendering.

Thanks.

--
Love feeling your best ever, all day, every day?
Click http://RadicalHealth.com for the easy way!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Burner-3]

On 2010-05-27 14:14, David Favor wrote:
> Someone let me know the command line for converting
> .mts AVCHD files to a format Final Cut Pro can ingest
> and use without re-rendering.

I second that question :)
And if someone found a good way to do the same for Premiere Pro as well.

I tested with huffyuv, but didnt find a way to avoid re-rendering.



_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Walter Werner]

> Someone let me know the command line for converting
> .mts AVCHD files to a format Final Cut Pro can ingest
> and use without re-rendering.
What is the native container format and what are the accepted native
codecs and frame sizes of Final Cut Pro?
AVCHD files are mpeg4 coded HD video in a special container.
>
>
> Thanks.
>
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[David Favor]

Walter Werner wrote:
>
>> Someone let me know the command line for converting
>> .mts AVCHD files to a format Final Cut Pro can ingest
>> and use without re-rendering.

> What is the native container format and what are the accepted native
> codecs and frame sizes of Final Cut Pro?
> AVCHD files are mpeg4 coded HD video in a special container.

Tough to know for sure exactly. Looks like Quicktime & ProRes is
the native format. Flarg... Looks ugly since ProRes support work
is still in process for ffmpeg.

Ah... wait... At this link there's interesting info:

    http://www.apple.com/finalcutstudio/finalcutpro/broad-format-support.html

Looks like DVCPRO-HD is supported natively.

Looks like ffmpeg supports DVCPRO50 (SD) encode + decode
and DVCPRO100 (HD) decode only.

Oddly examples of command line syntax working with either
DV50 or DV100 seems sparse.

I'll ping this list back for a request for encoding examples
in both.

--
Love feeling your best ever, all day, every day?
Click http://RadicalHealth.com for the easy way!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Thomas Worth-2]

On Thu, May 27, 2010 at 6:27 AM, David Favor <[hidden email]> wrote:

> Walter Werner wrote:
>>
>>> Someone let me know the command line for converting
>>> .mts AVCHD files to a format Final Cut Pro can ingest
>>> and use without re-rendering.
>
>> What is the native container format and what are the accepted native
>> codecs and frame sizes of Final Cut Pro?
>> AVCHD files are mpeg4 coded HD video in a special container.
>
> Tough to know for sure exactly. Looks like Quicktime & ProRes is
> the native format. Flarg... Looks ugly since ProRes support work
> is still in process for ffmpeg.
>
> Ah... wait... At this link there's interesting info:
>
>   http://www.apple.com/finalcutstudio/finalcutpro/broad-format-support.html
>
> Looks like DVCPRO-HD is supported natively.
>
> Looks like ffmpeg supports DVCPRO50 (SD) encode + decode
> and DVCPRO100 (HD) decode only.
>
> Oddly examples of command line syntax working with either
> DV50 or DV100 seems sparse.

We've spent countless hours researching this, and here's the deal:

The de facto way to edit AVC/H.264 with Final Cut Pro is to transcode
to Apple ProRes. It is one of the few codecs that allow realtime
effects without rendering. Off the top of my head, the only other
codecs that allow realtime editing are DV (NTSC/PAL) and DVCPRO HD.

I don't think FFmpeg is capable of encoding "dvvideo" in a way that
Apple's DVCPRO HD decoder expects. Even if this was possible, DVCPRO
HD tops out at a resolution of 1440x1080, so you would not get a full
raster 1920x1080 encode of the luma channel (many AVC codecs will
encode luma at 1920x1080, the Canon SLRs are an example). Result: loss
of resolution.

Unless this has been fixed recently, swscale will not detect Y Cr Cb
values outside the 16-235 range. Although flags exist to enable this
behavior, they don't work on the command line. So, if you are
transcoding footage from a camera that encodes AVC as 0-255 (Canon
SLRs do), FFmpeg will clip data off the top and bottom end of the
picture, resulting in loss of data.

We are working on an avcodec-enabled app called "5DtoRGB" that
addresses all of these problems. Although it was originally developed
to work with Canon SLRs, it will work with almost any camera that
records to AVC/H.264. Here's a link: http://rarevision.com/5dtorgb/

If you want to send me some sample footage, I'll test it with our
software. If I can get it to transcode, I'll send you a copy and you
can try it yourself.

Thomas
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[David Favor]

Thomas Worth wrote:

> On Thu, May 27, 2010 at 6:27 AM, David Favor <[hidden email]> wrote:
>> Walter Werner wrote:
>>>> Someone let me know the command line for converting
>>>> .mts AVCHD files to a format Final Cut Pro can ingest
>>>> and use without re-rendering.
>>> What is the native container format and what are the accepted native
>>> codecs and frame sizes of Final Cut Pro?
>>> AVCHD files are mpeg4 coded HD video in a special container.
>> Tough to know for sure exactly. Looks like Quicktime & ProRes is
>> the native format. Flarg... Looks ugly since ProRes support work
>> is still in process for ffmpeg.
>>
>> Ah... wait... At this link there's interesting info:
>>
>>   http://www.apple.com/finalcutstudio/finalcutpro/broad-format-support.html
>>
>> Looks like DVCPRO-HD is supported natively.
>>
>> Looks like ffmpeg supports DVCPRO50 (SD) encode + decode
>> and DVCPRO100 (HD) decode only.
>>
>> Oddly examples of command line syntax working with either
>> DV50 or DV100 seems sparse.
>
> We've spent countless hours researching this, and here's the deal:
>
> The de facto way to edit AVC/H.264 with Final Cut Pro is to transcode
> to Apple ProRes. It is one of the few codecs that allow realtime
> effects without rendering. Off the top of my head, the only other
> codecs that allow realtime editing are DV (NTSC/PAL) and DVCPRO HD.
>
> I don't think FFmpeg is capable of encoding "dvvideo" in a way that
> Apple's DVCPRO HD decoder expects. Even if this was possible, DVCPRO
> HD tops out at a resolution of 1440x1080, so you would not get a full
> raster 1920x1080 encode of the luma channel (many AVC codecs will
> encode luma at 1920x1080, the Canon SLRs are an example). Result: loss
> of resolution.
>
> Unless this has been fixed recently, swscale will not detect Y Cr Cb
> values outside the 16-235 range. Although flags exist to enable this
> behavior, they don't work on the command line. So, if you are
> transcoding footage from a camera that encodes AVC as 0-255 (Canon
> SLRs do), FFmpeg will clip data off the top and bottom end of the
> picture, resulting in loss of data.
>
> We are working on an avcodec-enabled app called "5DtoRGB" that
> addresses all of these problems. Although it was originally developed
> to work with Canon SLRs, it will work with almost any camera that
> records to AVC/H.264. Here's a link: http://rarevision.com/5dtorgb/
>
> If you want to send me some sample footage, I'll test it with our
> software. If I can get it to transcode, I'll send you a copy and you
> can try it yourself.
>
> Thomas

I have footage from both a Vixia HFS100 and Panasonic HDC-TM700. The
Vixia is 1080i and Panasonic is 1080p.

I'll put up some footage somewhere on one of my servers for you to
download... and... I'm happy to do a preconversion to something like
pure yuv if required.

CPU and cycle time is no issue prior to using a film editor. My goal
is to run all the preconversions/transcoding in background, then edit
without rendering when I get to the Final Cut Pro stage of my process.

I'll send you links to the footage when the upload is complete.

And as I said, preconversion is no problem, so you're welcome to send
me a copy of your code and tell me what import format is required and
I'll transcode to your expected input format.

Thanks for your quick reply!

- David

--
Love feeling your best ever, all day, every day?
Click http://RadicalHealth.com for the easy way!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

Hi,

On 05/27/2010 07:09 AM, Thomas Worth wrote:
 > [...]
 >
> I don't think FFmpeg is capable of encoding "dvvideo" in a way that
> Apple's DVCPRO HD decoder expects. Even if this was possible, DVCPRO
> HD tops out at a resolution of 1440x1080, so you would not get a full
> raster 1920x1080 encode of the luma channel (many AVC codecs will
> encode luma at 1920x1080, the Canon SLRs are an example). Result: loss
> of resolution.

There is a patch around that provides DVCPRO HD encoding perfectly
compatible with Final Cut Pro.

> Unless this has been fixed recently, swscale will not detect Y Cr Cb
> values outside the 16-235 range. Although flags exist to enable this
> behavior, they don't work on the command line. So, if you are
> transcoding footage from a camera that encodes AVC as 0-255 (Canon
> SLRs do), FFmpeg will clip data off the top and bottom end of the
> picture, resulting in loss of data.

Could you please share a sample ? If that's the case it would be nice to
fix this problem.

> We are working on an avcodec-enabled app called "5DtoRGB" that
> addresses all of these problems. Although it was originally developed
> to work with Canon SLRs, it will work with almost any camera that
> records to AVC/H.264. Here's a link: http://rarevision.com/5dtorgb/

This is great, just please keep in mind that FFmpeg (avcodec) is LGPL,
so you must comply with the license.

[...]

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Phil Rhodes]

> There is a patch around that provides DVCPRO HD encoding perfectly
> compatible with Final Cut Pro.

This has been the case for at least several years and I was beginning to
assume that there was some sort of conspiracy to keep DVHD out of ffmpeg!

> FFmpeg will clip data off the top and bottom end of the
>> picture, resulting in loss of data.
>
> Could you please share a sample ? If that's the case it would be nice to
> fix this problem.

I think this has also been known for quite some time...

P

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

On 05/27/2010 01:55 PM, Phil Rhodes wrote:

>> There is a patch around that provides DVCPRO HD encoding perfectly
>> compatible with Final Cut Pro.
>
> This has been the case for at least several years and I was beginning to
> assume that there was some sort of conspiracy to keep DVHD out of ffmpeg!
>
>> FFmpeg will clip data off the top and bottom end of the
>>> picture, resulting in loss of data.
>>
>> Could you please share a sample ? If that's the case it would be nice to
>> fix this problem.
>
> I think this has also been known for quite some time...

No, I think you are confused.
He says that the camera stores YUV using the full range 0-255.
AFAIK this is really _unusual_ for H.264.

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Thomas Worth-2]

On Thu, May 27, 2010 at 11:49 AM, Baptiste Coudurier
<[hidden email]> wrote:

> Hi,
>
> On 05/27/2010 07:09 AM, Thomas Worth wrote:
>> [...]
>>
>>
>> I don't think FFmpeg is capable of encoding "dvvideo" in a way that
>> Apple's DVCPRO HD decoder expects. Even if this was possible, DVCPRO
>> HD tops out at a resolution of 1440x1080, so you would not get a full
>> raster 1920x1080 encode of the luma channel (many AVC codecs will
>> encode luma at 1920x1080, the Canon SLRs are an example). Result: loss
>> of resolution.
>
> There is a patch around that provides DVCPRO HD encoding perfectly
> compatible with Final Cut Pro.

Yeah, I've heard of this but haven't fully investigated. Besides, we
mainly deal in high end post, and DVCPRO HD is falling out of style
for this because of the limitations I mentioned.


>> Unless this has been fixed recently, swscale will not detect Y Cr Cb
>> values outside the 16-235 range. Although flags exist to enable this
>> behavior, they don't work on the command line. So, if you are
>> transcoding footage from a camera that encodes AVC as 0-255 (Canon
>> SLRs do), FFmpeg will clip data off the top and bottom end of the
>> picture, resulting in loss of data.
>
> Could you please share a sample ? If that's the case it would be nice to fix
> this problem.

There was a long conversation about this a few months back, but I'm
happy to provide some Canon footage. I can also show the decompression
result from Apple's H.264 decoder (which properly sees 0-255) and
avcodec's.


>> We are working on an avcodec-enabled app called "5DtoRGB" that
>> addresses all of these problems. Although it was originally developed
>> to work with Canon SLRs, it will work with almost any camera that
>> records to AVC/H.264. Here's a link: http://rarevision.com/5dtorgb/
>
> This is great, just please keep in mind that FFmpeg (avcodec) is LGPL, so
> you must comply with the license.

Yes, we fully intend to and have structured our apps accordingly.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

On 05/27/2010 04:29 PM, Thomas Worth wrote:

>>> [...]
>>>
>>> Unless this has been fixed recently, swscale will not detect Y Cr Cb
>>> values outside the 16-235 range. Although flags exist to enable this
>>> behavior, they don't work on the command line. So, if you are
>>> transcoding footage from a camera that encodes AVC as 0-255 (Canon
>>> SLRs do), FFmpeg will clip data off the top and bottom end of the
>>> picture, resulting in loss of data.
>>
>> Could you please share a sample ? If that's the case it would be nice to fix
>> this problem.
>
> There was a long conversation about this a few months back, but I'm
> happy to provide some Canon footage. I can also show the decompression
> result from Apple's H.264 decoder (which properly sees 0-255) and
> avcodec's.
>

That would be great.

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Thomas Worth-2]

On Thu, May 27, 2010 at 2:22 PM, Baptiste Coudurier
<[hidden email]> wrote:

> On 05/27/2010 01:55 PM, Phil Rhodes wrote:
>>>
>>> There is a patch around that provides DVCPRO HD encoding perfectly
>>> compatible with Final Cut Pro.
>>
>> This has been the case for at least several years and I was beginning to
>> assume that there was some sort of conspiracy to keep DVHD out of ffmpeg!
>>
>>> FFmpeg will clip data off the top and bottom end of the
>>>>
>>>> picture, resulting in loss of data.
>>>
>>> Could you please share a sample ? If that's the case it would be nice to
>>> fix this problem.
>>
>> I think this has also been known for quite some time...
>
> No, I think you are confused.
> He says that the camera stores YUV using the full range 0-255.
> AFAIK this is really _unusual_ for H.264.

It is indeed unusual, but is the case. This can be verified by using
FFmpeg to output raw YUV from Canon files (before passing it to
swscale). You'll see that values below 16 and above 235 exist in Y.

Keep in mind that the Canon SLRs shoot high bitrate H.264 which is,
from what I can tell, not necessarily intended to be broadcast
compliant. I suspect Canon decided to maximize the already limited 8
bit range by filling it completely, rather than chopping off the ends
for the sake of satisfying broadcast compatibility. This was a wise
choice, as professionals will perform some type of picture
manipulation (color correction, for example) prior to final output.
And since the footage is already compressed, every little bit of extra
data helps.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Thomas Worth-2]

On Thu, May 27, 2010 at 4:39 PM, Baptiste Coudurier
<[hidden email]> wrote:

> On 05/27/2010 04:29 PM, Thomas Worth wrote:
>>>>
>>>> [...]
>>>>
>>>> Unless this has been fixed recently, swscale will not detect Y Cr Cb
>>>> values outside the 16-235 range. Although flags exist to enable this
>>>> behavior, they don't work on the command line. So, if you are
>>>> transcoding footage from a camera that encodes AVC as 0-255 (Canon
>>>> SLRs do), FFmpeg will clip data off the top and bottom end of the
>>>> picture, resulting in loss of data.
>>>
>>> Could you please share a sample ? If that's the case it would be nice to
>>> fix
>>> this problem.
>>
>> There was a long conversation about this a few months back, but I'm
>> happy to provide some Canon footage. I can also show the decompression
>> result from Apple's H.264 decoder (which properly sees 0-255) and
>> avcodec's.
>>
>
> That would be great.

This attempts to explain the problem:

http://gunshotfx.com/libavcodec/

I can send you some other formats if you want, since the camera also
shoots 720p, SD and in 29.97 and 59.94.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

On 05/27/2010 06:03 PM, Thomas Worth wrote:

> On Thu, May 27, 2010 at 2:22 PM, Baptiste Coudurier
> <[hidden email]>  wrote:
>> On 05/27/2010 01:55 PM, Phil Rhodes wrote:
>>>>
>>>> There is a patch around that provides DVCPRO HD encoding perfectly
>>>> compatible with Final Cut Pro.
>>>
>>> This has been the case for at least several years and I was beginning to
>>> assume that there was some sort of conspiracy to keep DVHD out of ffmpeg!
>>>
>>>> FFmpeg will clip data off the top and bottom end of the
>>>>>
>>>>> picture, resulting in loss of data.
>>>>
>>>> Could you please share a sample ? If that's the case it would be nice to
>>>> fix this problem.
>>>
>>> I think this has also been known for quite some time...
>>
>> No, I think you are confused.
>> He says that the camera stores YUV using the full range 0-255.
>> AFAIK this is really _unusual_ for H.264.
>
> It is indeed unusual, but is the case. This can be verified by using
> FFmpeg to output raw YUV from Canon files (before passing it to
> swscale). You'll see that values below 16 and above 235 exist in Y.
>
> Keep in mind that the Canon SLRs shoot high bitrate H.264 which is,
> from what I can tell, not necessarily intended to be broadcast
> compliant. I suspect Canon decided to maximize the already limited 8
> bit range by filling it completely, rather than chopping off the ends
> for the sake of satisfying broadcast compatibility.

Why are you talking about broadcast compliancy ?
If it is allowed and possible to store full range yuv in H.264 (by the
specifications) then it is valid and not treating it correctly is a bug.

If it's not allowed by the specs, then it is another story.

> This was a wise choice, as professionals will perform some type of picture
> manipulation (color correction, for example) prior to final output.
> And since the footage is already compressed, every little bit of extra
> data helps.

It all depends on how your products works, if the tools work on YUV
normal range this is useless and harmful, because it forces another
conversion.

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Phil Rhodes]

> It all depends on how your products works, if the tools work on YUV
> normal range this is useless and harmful, because it forces another
> conversion.

I don't think that's the case here. High end people will want to work on it
in RGB, which would mean scaling up 709-range images. Everyone else will
want to work on it in 709 YUV, which will crop data off. Regardless of the
spec it is actually quite hard to work on right now since even ffmpeg can't
handle it right.

Speaking generally this is the second instance we've found of software that
doesn't properly handle luminance ranging issues (the other being
Blackmagic's hardware drivers and associated code) and it is well worth
fixing. Ffmpeg has the potential to be a problem solver in this regard.

P

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

On 05/27/2010 06:51 PM, Phil Rhodes wrote:
>> It all depends on how your products works, if the tools work on YUV
>> normal range this is useless and harmful, because it forces another
>> conversion.
>
> I don't think that's the case here. High end people will want to work on
> it in RGB which would mean scaling up 709-range images.

In this case it doesn't matter, you still have to convert from yuv 0-255
to rgb, so that would it makes it a _bad_ decision because most of the
cases you have to convert _anyway_.

> [...]
 >
> Speaking generally this is the second instance we've found of software
> that doesn't properly handle luminance ranging issues (the other being
> Blackmagic's hardware drivers and associated code) and it is well worth
> fixing. Ffmpeg has the potential to be a problem solver in this regard.

Well if the files really stores yuv full range, the fix is rather
trivial: find the mechanism used to specify in the h.264 bitstream that
the file is using yuv full range, and set the colorspace to
PIX_FMT_YUVJ420P.

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Thomas Worth-2]

On Thu, May 27, 2010 at 6:54 PM, Baptiste Coudurier
<[hidden email]> wrote:

> On 05/27/2010 06:51 PM, Phil Rhodes wrote:
>>>
>>> It all depends on how your products works, if the tools work on YUV
>>> normal range this is useless and harmful, because it forces another
>>> conversion.
>>
>> I don't think that's the case here. High end people will want to work on
>> it in RGB which would mean scaling up 709-range images.
>
> In this case it doesn't matter, you still have to convert from yuv 0-255 to
> rgb, so that would it makes it a _bad_ decision because most of the cases
> you have to convert _anyway_.

The reason it's a good decision is because there is no advantage in
this case to throwing away data below 16 and above 235. The
disadvantage, though, is that the bit depth is lower (sub 8bit at this
point). Clearly, we have more picture information if full range values
are stored instead of 16-235. So, conversion or not, we are starting
the process with more data. That's always better.

Our software implements its own chroma interpolation and Y Cr Cb
decoding (doesn't use swscale), which is why this is less of an issue
for us. BUT, for others it would be good to be able to work with full
range values.


>> Speaking generally this is the second instance we've found of software
>> that doesn't properly handle luminance ranging issues (the other being
>> Blackmagic's hardware drivers and associated code) and it is well worth
>> fixing. Ffmpeg has the potential to be a problem solver in this regard.
>
> Well if the files really stores yuv full range, the fix is rather trivial:
> find the mechanism used to specify in the h.264 bitstream that the file is
> using yuv full range, and set the colorspace to PIX_FMT_YUVJ420P.

I'll test this and report the results.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Thomas Worth-2]

On Thu, May 27, 2010 at 6:51 PM, Phil Rhodes <[hidden email]> wrote:

>> It all depends on how your products works, if the tools work on YUV
>> normal range this is useless and harmful, because it forces another
>> conversion.
>
> I don't think that's the case here. High end people will want to work on it
> in RGB, which would mean scaling up 709-range images. Everyone else will
> want to work on it in 709 YUV, which will crop data off. Regardless of the
> spec it is actually quite hard to work on right now since even ffmpeg can't
> handle it right.
>
> Speaking generally this is the second instance we've found of software that
> doesn't properly handle luminance ranging issues (the other being
> Blackmagic's hardware drivers and associated code) and it is well worth
> fixing. Ffmpeg has the potential to be a problem solver in this regard.

Yeah, everyone is terrified about the possibility that their files
won't be compatible with broadcast gear. Blackmagic Design software
codecs always clip output to 16-235 (64-940 in the case of 10 bit),
even if the input was full range. This is OK if your workflow includes
strictly broadcast range footage, but for film work (this is mostly
what we do) this is obviously not applicable. We still get clamped
range footage all the time because clients shoot on broadcast gear for
theatrical purposes. The Canons, however, are unique in this regard as
they don't clamp like many broadcast cameras.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

On 05/27/2010 07:30 PM, Thomas Worth wrote:

> On Thu, May 27, 2010 at 6:54 PM, Baptiste Coudurier
> <[hidden email]>  wrote:
>> On 05/27/2010 06:51 PM, Phil Rhodes wrote:
>>>>
>>>> It all depends on how your products works, if the tools work on YUV
>>>> normal range this is useless and harmful, because it forces another
>>>> conversion.
>>>
>>> I don't think that's the case here. High end people will want to work on
>>> it in RGB which would mean scaling up 709-range images.
>>
>> In this case it doesn't matter, you still have to convert from yuv 0-255 to
>> rgb, so that would it makes it a _bad_ decision because most of the cases
>> you have to convert _anyway_.
>
> The reason it's a good decision is because there is no advantage in
> this case to throwing away data below 16 and above 235. The
> disadvantage, though, is that the bit depth is lower (sub 8bit at this
> point). Clearly, we have more picture information if full range values
> are stored instead of 16-235. So, conversion or not, we are starting
> the process with more data. That's always better.

It's not always better if the data is going to be discarded _anyway_, in
your case it may be better.
Now like you saw many tools just do not support it.
If the tool support regular yuv video pipeline, you have to convert your
full range to regular which is costly, adding a full range yuv video
pipeling could be costly to the product if it was not planned, so it
will just convert the full range to the regular range and use the
existing pipeline without even telling you. If it was regular range you
wouldn't have to convert.

> Our software implements its own chroma interpolation and Y Cr Cb
> decoding (doesn't use swscale), which is why this is less of an issue
> for us. BUT, for others it would be good to be able to work with full
> range values.

libavcodec will output full range and set AVCOL_RANGE_JPEG, application
can check for this.
If this happens, use PIX_FMT_YUVJ420P instead of PIX_FMT_YUV420P in
libswscale and it should work.

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

On 05/27/2010 07:30 PM, Thomas Worth wrote:

> On Thu, May 27, 2010 at 6:54 PM, Baptiste Coudurier
> <[hidden email]>  wrote:
>> On 05/27/2010 06:51 PM, Phil Rhodes wrote:
>>>>
>>>> It all depends on how your products works, if the tools work on YUV
>>>> normal range this is useless and harmful, because it forces another
>>>> conversion.
>>>
>>> I don't think that's the case here. High end people will want to work on
>>> it in RGB which would mean scaling up 709-range images.
>>
>> In this case it doesn't matter, you still have to convert from yuv 0-255 to
>> rgb, so that would it makes it a _bad_ decision because most of the cases
>> you have to convert _anyway_.
>
> The reason it's a good decision is because there is no advantage in
> this case to throwing away data below 16 and above 235. The
> disadvantage, though, is that the bit depth is lower (sub 8bit at this
> point). Clearly, we have more picture information if full range values
> are stored instead of 16-235. So, conversion or not, we are starting
> the process with more data. That's always better.

It's not always better if the data is going to be discarded _anyway_, in
your case it may be better.
Now like you saw many tools just do not support it.
If the tool support regular yuv video pipeline, you have to convert your
full range to regular which is costly, adding a full range yuv video
pipeling could be costly to the product if it was not planned, so it
will just convert the full range to the regular range and use the
existing pipeline without even telling you. If it was regular range you
wouldn't have to convert.

> Our software implements its own chroma interpolation and Y Cr Cb
> decoding (doesn't use swscale), which is why this is less of an issue
> for us. BUT, for others it would be good to be able to work with full
> range values.

libavcodec will output full range and set AVCOL_RANGE_JPEG, application
can check for this.
If this happens, use PIX_FMT_YUVJ420P instead of PIX_FMT_YUV420P in
libswscale and it should work.

--
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user