Signed-off-by: Paras Chadha
---
Add FATE coverage
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/fitsdec.c | 231 ++
libavformat/version.h | 2 +-
tests/fate/demux.mak | 3 +
On Sun, Aug 6, 2017 at 5:27 PM, Nicolas George wrote:
> Le duodi 12 thermidor, an CCXXV, Paras Chadha a écrit :
> > But i am returning the size from this function. If i make them unsigned,
> > how will i return errors which are negative integers.
> > One thing i can do is pass
Signed-off-by: Paras Chadha
---
Made changes suggested.
Refactored Code
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/fitsdec.c| 231 +++
libavformat/version.h| 2 +-
4 files
Le duodi 12 thermidor, an CCXXV, Paras Chadha a écrit :
> But i am returning the size from this function. If i make them unsigned,
> how will i return errors which are negative integers.
> One thing i can do is pass data_size as pointer to the function. Should i
> do that ?
No need: you can make
On Fri, Jul 28, 2017 at 3:26 PM, Nicolas George wrote:
> Le decadi 10 thermidor, an CCXXV, Paras Chadha a écrit :
> > Signed-off-by: Paras Chadha
> > ---
> >
> > Made all the changes suggested.
>
> Nice. There are a few nitpicks, but I like these
Le decadi 10 thermidor, an CCXXV, Paras Chadha a écrit :
> Signed-off-by: Paras Chadha
> ---
>
> Made all the changes suggested.
Nice. There are a few nitpicks, but I like these versions much better.
>
> libavformat/Makefile | 1 +
> libavformat/allformats.c |
On Fri, Jul 28, 2017 at 1:44 PM, Clément Bœsch wrote:
> On Fri, Jul 28, 2017 at 12:32:59AM +0530, Paras Chadha wrote:
> [...]
> > +static int fits_probe(AVProbeData *p)
> > +{
> > +const uint8_t *b = p->buf;
> > +
> > +if (AV_RB64(b) == 0x53494d504c452020 &&
> > +
On Fri, Jul 28, 2017 at 12:32:59AM +0530, Paras Chadha wrote:
[...]
> +static int fits_probe(AVProbeData *p)
> +{
> +const uint8_t *b = p->buf;
> +
> +if (AV_RB64(b) == 0x53494d504c452020 &&
> +AV_RB64(b + 8) == 0x3D20202020202020 &&
> +AV_RB64(b + 16) == 0x2020202020202020
Signed-off-by: Paras Chadha
---
Made all the changes suggested.
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/fitsdec.c| 236 +++
libavformat/version.h| 2 +-
4 files changed, 239
Le tridi 3 thermidor, an CCXXV, Paras Chadha a écrit :
> The only difference between first image and rest is that, the first image
> will always contain the keyword, SIMPLE = T as first keyword while all
> other images will have XTENSION = 'IMAGE ' as first keyword.
Then I would say that "SIMPLE
On Thu, Jul 20, 2017 at 11:17 PM, Nicolas George wrote:
> Le primidi 1er thermidor, an CCXXV, Reimar Döffinger a écrit :
> > I am a bit unclear on the details, but my memory:
> > Well, they work better (only?) if the images are completely independent.
>
> > I am not sure this is
Le primidi 1er thermidor, an CCXXV, Reimar Döffinger a écrit :
> I am a bit unclear on the details, but my memory:
> Well, they work better (only?) if the images are completely independent.
> I am not sure this is entirely the case here, for example the first
> image would have a different header
Le duodi 2 thermidor, an CCXXV, Paul B Mahol a écrit :
> You should be more constructive, better go porting dualinput to framesync2,
> that wasting everybodies precious time here.
Keeping high standards of code quality seems to me a more important use
of my time. And since you are neither my boss
On 7/20/17, Nicolas George wrote:
> Le duodi 2 thermidor, an CCXXV, Paul B Mahol a ecrit :
>> Assuming there are no comments.
>
> Wrong. Give me more time.
You should be more constructive, better go porting dualinput to framesync2,
that wasting everybodies precious time here.
Le duodi 2 thermidor, an CCXXV, Paul B Mahol a écrit :
> Assuming there are no comments.
Wrong. Give me more time.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 7/19/17, Paul B Mahol wrote:
> On 7/19/17, Nicolas George wrote:
>> Le primidi 1er thermidor, an CCXXV, Paul B Mahol a ecrit :
>>> If you had ever write parser, you would know that this above is
>>> giberish.
>>
>> Please enlighten us.
>
> Are there more
On 19.07.2017, at 12:03, Nicolas George wrote:
> What I do insist on, is this:
>
> Look at the find_size() function in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213076.html
>
> Then look at the fits_read_header() in this patch:
>
On 19.07.2017, at 12:03, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a écrit :
>
>> I think the image2 demuxer shouldn't handle this type of junk/useless data
>> filtering and would rather see a separate demuxer like the current patch
>> which
On 7/19/17, Nicolas George wrote:
> Le primidi 1er thermidor, an CCXXV, Paul B Mahol a ecrit :
>> If you had ever write parser, you would know that this above is giberish.
>
> Please enlighten us.
Are there more than one Nicolas here?
Anyway the input can be of any size so one
Le primidi 1er thermidor, an CCXXV, Paul B Mahol a écrit :
> If you had ever write parser, you would know that this above is giberish.
Please enlighten us.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel
On 7/19/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a ecrit :
>> Its a crappy format, no reason to blame anyone else but the format.
>> We have plenty of crappy formats which have no clear separation between
>> packets so demuxers have to
Le primidi 1er thermidor, an CCXXV, Paul B Mahol a écrit :
> Except when those standards need to be applied to your work.
Yet another ad-hominem attack.
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
On 7/19/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a ecrit :
>> Its a crappy format, no reason to blame anyone else but the format.
>> We have plenty of crappy formats which have no clear separation between
>> packets so demuxers have to
Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a écrit :
> Its a crappy format, no reason to blame anyone else but the format.
> We have plenty of crappy formats which have no clear separation between
> packets so demuxers have to give not-entirely-demuxed packets to the
> decoder which
On 18 July 2017 at 19:42, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> > To not cause drama on git repo I kindly ask Michael to remove your git
> > push access.
>
> I will leave the people who have that kind of power judge who must be
>
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> To not cause drama on git repo I kindly ask Michael to remove your git
> push access.
I will leave the people who have that kind of power judge who must be
banished :
The one who made useful reviews to the patches, with constructive
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> Design is just fine. You need to be more constructive, otherwise I will
>> just assume you want to be evil and ignore your comments.
>
> This is not true, anybody who reads the
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> Design is just fine. You need to be more constructive, otherwise I will
> just assume you want to be evil and ignore your comments.
This is not true, anybody who reads the mailing-list can see it (I can
provide links if necessary).
Please
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> You are unable to work with as a team.
>
> You may notice that my message did not contain anything ad-hominem.
> This, on the other hand, is pure ad-hoinem.
>
>> I see nothing wrong
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> You are unable to work with as a team.
You may notice that my message did not contain anything ad-hominem.
This, on the other hand, is pure ad-hoinem.
> I see nothing wrong with either demuxer or decoder code and no
> duplicated lines of
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>>I will fork FFmpeg.
>
> It is the third time you make that threat. Out of principle, I want to
> reply to anybody making it : please go ahead and good riddance.
>
>
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I will fork FFmpeg.
It is the third time you make that threat. Out of principle, I want to
reply to anybody making it : please go ahead and good riddance.
Seriously, only somebody unable to working in a team and respecting
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> I'm not going to listen your non-useful comments.
>
> My comments have been constructive. Pushing with outstanding objections
> like that is against the project policy. If you do it on
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I'm not going to listen your non-useful comments.
My comments have been constructive. Pushing with outstanding objections
like that is against the project policy. If you do it on purpose, your
Git right should be revoked.
--
Nicolas
On 7/18/17, Nicolas George wrote:
> Le decadi 30 messidor, an CCXXV, Paul B Mahol a ecrit :
>> I believe your approach is fine.
>
> The huge duplication between decoder and demuxer is definitely not fine.
> You need to find a solution before pushing anything.
I'm not going to
Le decadi 30 messidor, an CCXXV, Paul B Mahol a écrit :
> I believe your approach is fine.
The huge duplication between decoder and demuxer is definitely not fine.
You need to find a solution before pushing anything.
Regards,
--
Nicolas George
___
On 7/16/17, Paras Chadha wrote:
> On Sun, Jul 16, 2017 at 10:06 PM, Paul B Mahol wrote:
>
>> Can you give link to file which holds more than one FITS image?
>>
>
> Yes, here is the file: https://fits.gsfc.nasa.gov/samples/EUVEngc4151imgx.
> fits
>
I
On Sun, Jul 16, 2017 at 10:06 PM, Paul B Mahol wrote:
> Can you give link to file which holds more than one FITS image?
>
Yes, here is the file: https://fits.gsfc.nasa.gov/samples/EUVEngc4151imgx.
fits
> ___
> ffmpeg-devel mailing
Can you give link to file which holds more than one FITS image?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Le tridi 23 messidor, an CCXXV, Paras Chadha a écrit :
> Hi, I have attached the dump of a FITS File containing 5 images and 4
> binary table xtensions. The dump is taken using fdump utility. Please take
> a look.
Thanks for the dump. But it is you who know the format, thus it is you
who can tell
On Tue, Jul 11, 2017 at 3:41 PM, Nicolas George wrote:
> Le decadi 20 messidor, an CCXXV, Reimar Döffinger a écrit :
> > I don't think that's a correct description then.
> > First, the format is made to change and be extended, so what is
> > true now might not stay true.
> > But
On Tue, Jul 11, 2017 at 3:41 PM, Nicolas George wrote:
> Le decadi 20 messidor, an CCXXV, Reimar Döffinger a écrit :
> > I don't think that's a correct description then.
> > First, the format is made to change and be extended, so what is
> > true now might not stay true.
> > But
Le decadi 20 messidor, an CCXXV, Reimar Döffinger a écrit :
> I don't think that's a correct description then.
> First, the format is made to change and be extended, so what is
> true now might not stay true.
> But also the images can have arbitrary dimensions, in particular
> they can be "3D"
On Tue, Jul 04, 2017 at 09:50:31PM +0530, Paras Chadha wrote:
> On Tue, Jul 4, 2017 at 4:12 AM, Reimar Döffinger
> wrote:
> > > +data_size *= naxisn[i];
> > > +if (data_size < 0)
> > > +return AVERROR_INVALIDDATA;
> >
> > If this
On Sat, Jul 08, 2017 at 12:59:09PM +0200, Nicolas George wrote:
> Le sextidi 16 messidor, an CCXXV, Paras Chadha a écrit :
> > So, now should i do this ?
>
> Based on what you explained here, FITS seems like just an image format,
> without provisions for animations like GIF or PNG. Therefore, it
Le sextidi 16 messidor, an CCXXV, Paras Chadha a écrit :
> So, now should i do this ?
Based on what you explained here, FITS seems like just an image format,
without provisions for animations like GIF or PNG. Therefore, it should
have been integrated in the img2 framework in the first place and
On Tue, Jul 4, 2017 at 10:20 PM, Nicolas George wrote:
> Le sextidi 16 messidor, an CCXXV, Paras Chadha a écrit :
> > There is no global header.
> >
> > Basically FITS files can have multiple images.
>
>
> Thanks for all the details. When there are several images, they are all
Le sextidi 16 messidor, an CCXXV, Paras Chadha a écrit :
> There is no global header.
>
> Basically FITS files can have multiple images.
Thanks for all the details. When there are several images, they are all
one after the other?
If so, then I really think you should stop the demuxer and
On Tue, Jul 4, 2017 at 2:51 PM, Nicolas George wrote:
> Le quartidi 14 messidor, an CCXXV, Paras Chadha a écrit :
> > Filled buf with 0 to prevent overfow
> > Also added checks for integer overflow
> >
> > Signed-off-by: Paras Chadha
> > ---
> >
On Tue, Jul 4, 2017 at 4:12 AM, Reimar Döffinger
wrote:
>
> > +static int64_t find_size(AVIOContext * pb, FITSContext * fits)
> > +{
> > +int bitpix, naxis, dim_no, i, naxisn[999], groups=0;
> > +int64_t header_size = 0, data_size=0, ret, pcount=0, gcount=1, d;
Le sextidi 16 messidor, an CCXXV, Nicolas George a écrit :
> If you change that into "a handful of kilo-octets", then for a project
> like FFmpeg (which is not a monster like a Gui toolkit but neither meant
> for embedded systems with tiny limits) I agree.
>
> But "a handful bytes", I consider
Le sextidi 16 messidor, an CCXXV, Reimar Döffinger a écrit :
> From a security standpoint, I believe any array and anything that is
> more than a handful bytes ideally should not be on the stack, if the
> added complexity is minimal.
If you change that into "a handful of kilo-octets", then for a
Le quartidi 14 messidor, an CCXXV, Paras Chadha a écrit :
> Filled buf with 0 to prevent overfow
> Also added checks for integer overflow
>
> Signed-off-by: Paras Chadha
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
>
On Tue, 4 Jul 2017 08:42:56 +0200
Reimar Döffinger wrote:
> On 04.07.2017, at 00:51, Nicolas George wrote:
>
> > Hi. Nice to see you back.
> >
> > Le sextidi 16 messidor, an CCXXV, Reimar Döffinger a écrit :
> >> This is more than 4kB of data on
On 04.07.2017, at 00:51, Nicolas George wrote:
> Hi. Nice to see you back.
>
> Le sextidi 16 messidor, an CCXXV, Reimar Döffinger a écrit :
>> This is more than 4kB of data on the stack.
>> Large stack arrays have a huge amount of security implications, please
>> put such
Hi. Nice to see you back.
Le sextidi 16 messidor, an CCXXV, Reimar Döffinger a écrit :
> This is more than 4kB of data on the stack.
> Large stack arrays have a huge amount of security implications, please
> put such buffers (if really needed) into the context.
4 ko is not large, and neither is
> +static int64_t find_size(AVIOContext * pb, FITSContext * fits)
> +{
> +int bitpix, naxis, dim_no, i, naxisn[999], groups=0;
> +int64_t header_size = 0, data_size=0, ret, pcount=0, gcount=1, d;
> +char buf[81], c;
This is more than 4kB of data on the stack.
Large stack arrays have
On Mon, Jul 3, 2017 at 3:56 AM, Moritz Barsnick wrote:
> On Sun, Jul 02, 2017 at 20:48:17 +0530, Paras Chadha wrote:
> > +int64_t header_size = 0, data_size=0, ret, pcount=0, gcount=1, d;
> [...]
> > +header_size += 80;
> [...]
> > +header_size += 80;
> [...]
> > +
On Sun, Jul 02, 2017 at 20:48:17 +0530, Paras Chadha wrote:
> +int64_t header_size = 0, data_size=0, ret, pcount=0, gcount=1, d;
[...]
> +header_size += 80;
[...]
> +header_size += 80;
[...]
> +header_size += 80;
[...]
> +for (i = 0; i < naxis; i++) {
[...]
> +
Filled buf with 0 to prevent overfow
Also added checks for integer overflow
Signed-off-by: Paras Chadha
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/fitsdec.c| 224 +++
Signed-off-by: Paras Chadha
---
Changelog| 2 +-
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/fitsdec.c| 207 +++
libavformat/version.h| 2 +-
5 files changed, 211
61 matches
Mail list logo