2018-02-12 23:38 GMT+01:00 Jerome Martinez :
> On 12/02/2018 22:37, Carl Eugen Hoyos wrote:
>> The only solution I can think of is to change the semantics of the fourth
>> dpx layer by default and to add an option (to the decoder) that allows
>> using the current semantics
On 12/02/2018 22:37, Carl Eugen Hoyos wrote:
2018-02-12 20:47 GMT+01:00 Jerome Martinez :
https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx
is indicated by the person who provided it as with DPX alpha channel used
for actually storing infrared
Thank
2018-02-12 20:47 GMT+01:00 Jerome Martinez :
> https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx
> is indicated by the person who provided it as with DPX alpha channel used
> for actually storing infrared
Thank you!
This sample appears to confirm that
On 09/02/2018 11:39, Carl Eugen Hoyos wrote:
I think the question is out of topic for this patch proposal, as this
question is global for all flavors of DPX (also the ones already supported
by FFmpeg, i.e. FFmpeg already supports RGBA 12-bit filled with Method A,
here I just add the support
On 09/02/2018 12:20, Kieran O Leary wrote:
Hi both,
I'm just wondering if the past duration errors in my earlier email mean
anything,or should they be ignored?
They are independent from the patch, e.g.:
https://stackoverflow.com/questions/30782771/what-does-past-duration-x-xxx-too-large-mean
Hi both,
I'm just wondering if the past duration errors in my earlier email mean
anything,or should they be ignored?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 09/02/2018 11:32, Carl Eugen Hoyos wrote:
[...] please mention ticket #5639 in the commit message.
I should definitely have indicated this source instead of my copy, my
mistake.
Commit message extended with it.
FYI I am running tests on several DPX flavors (to FFV1 and back to DPX,
2018-02-09 11:34 GMT+01:00 Jerome Martinez :
> On 09/02/2018 11:15, Carl Eugen Hoyos wrote:
>>
>>
>>> Sorry, I see a line was missing in my first post, the one with the link
>>> to
>>> the RGBA test file.
>>> Test file for RGBA 12-bit packed:
>>>
>>>
On 09/02/2018 11:15, Carl Eugen Hoyos wrote:
Sorry, I see a line was missing in my first post, the one with the link to
the RGBA test file.
Test file for RGBA 12-bit packed:
https://github.com/MediaArea/RAWcooked-RegressionTestingFiles/tree/master/Formats/DPX/Flavors/RGBA_12_Packed_BE
Is this
2018-02-09 11:15 GMT+01:00 Carl Eugen Hoyos :
> 2018-02-09 7:38 GMT+01:00 Jerome Martinez :
>> Sorry, I see a line was missing in my first post, the one with the link to
>> the RGBA test file.
>> Test file for RGBA 12-bit packed:
>>
2018-02-09 7:38 GMT+01:00 Jerome Martinez :
> On 09/02/2018 02:19, Carl Eugen Hoyos wrote:
>>
>> 2018-02-08 11:28 GMT+01:00 Jerome Martinez :
>>>
>>> Currently RGB and RGBA 12-bit are supported by DPX decoder only if
>>> component
>>> values are padded
On 09/02/2018 02:19, Carl Eugen Hoyos wrote:
2018-02-08 11:28 GMT+01:00 Jerome Martinez :
Currently RGB and RGBA 12-bit are supported by DPX decoder only if component
values are padded (packing "Filled to 32-bit words, method A").
This patch adds decoding of RGB
and RGBA
2018-02-08 11:28 GMT+01:00 Jerome Martinez :
> Currently RGB and RGBA 12-bit are supported by DPX decoder only if component
> values are padded (packing "Filled to 32-bit words, method A").
> This patch adds decoding of RGB
> and RGBA 12-bit with no padding (packing "Packed
Hi Jerome,
Thank you so much for this patch.
I ran a quick test and ffmpeg and ffplay seems to decode these files
just fine. I noticed that taking a short 12-bit sequence (i didn't
even realise that they were big endian actually) from the Blackmagic
Cintel Scanner turned into FFV1 version 3 in
Currently RGB and RGBA 12-bit are supported by DPX decoder only if
component values are padded (packing "Filled to 32-bit words, method A").
This patch adds decoding of RGB and RGBA 12-bit with no padding (packing
"Packed into 32-bit words").
As I have no file with line boundaries not aligned
15 matches
Mail list logo