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 data_size as pointe
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 t
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 versions much better.
>
Hi, sorry for the late r
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 | 1 +
> libavformat/fitsd
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 &&
> > +AV_RB64(b + 8) ==
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
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 entirely the case
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
http:/
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 than one Nicolas here?
>
> Anyway the i
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:
> https://ffmpeg.org/pipermail/ffmpeg-devel/
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 deals with crap.
>
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 would need to hold
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 ma
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 give not-entirely-dem
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
ff
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 give not-entirely-dem
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 also
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
> banished :
>
> The one
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
commen
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 mailing-list can see it (I
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 with either demuxer o
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 c
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.
>
> Seriously, only somebod
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 purpose, your
> Gi
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 Geo
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 listen your non-usef
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
___
f
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 believe your approach is fine. There could not
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 list
> ffmpeg-devel
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
On Fri, Jul 14, 2017 at 11:15 PM, Nicolas George wrote:
> 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 th
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 also the images c
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 also the images c
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" imag
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 is supposed to be overlow ch
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 s
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
wr
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
> one after the ot
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 integr
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
> > ---
> > libavformat/Makefile | 1 +
> > libavformat
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;
> > +char buf[81], c;
>
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 the
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 p
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 +
> libavformat/fitsdec.c| 224
>
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 the stack.
> >> Large stack arrays have a huge
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 buffers (if really need
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 w
> +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 a
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;
> [...]
> > +header_size += 8
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++) {
[...]
> +header_siz
57 matches
Mail list logo
