On Friday 29 April 2016 09:10:08 am Christoph Gisquet wrote:
> Hi,
>
> 2016-04-27 23:58 GMT+02:00 Carl Eugen Hoyos :
> > Mark Thompson jkqxz.net> writes:
> >> Unless someone can show what created this file and that
> >> it might make more, I suggest that the hack workaround
> >> should be removed.
On Sat, 30 Apr 2016, Michael Niedermayer wrote:
On Sat, Apr 30, 2016 at 10:12:11AM -0400, Ronald S. Bultje wrote:
Please revert it.
I would like to see the oppinion of the people who maintain
the mpeg ts demuxer before its reverted.
MAINTAINERs lists Marton for mpegts.c
in practice i did tr
On Sat, Apr 30, 2016 at 10:12:11AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Apr 30, 2016 at 9:02 AM, Carl Eugen Hoyos wrote:
>
> > > cane please revert this patch?
> > > I don't think there's wide support for it.
> >
> > Two developers seem to wait for an explanation why it should be re
On 4/30/2016 11:12 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Apr 30, 2016 at 9:02 AM, Carl Eugen Hoyos wrote:
>
>>> cane please revert this patch?
>>> I don't think there's wide support for it.
>>
>> Two developers seem to wait for an explanation why it should be reverted.
>
>
> Last time
Hi,
On Sat, Apr 30, 2016 at 9:02 AM, Carl Eugen Hoyos wrote:
> > cane please revert this patch?
> > I don't think there's wide support for it.
>
> Two developers seem to wait for an explanation why it should be reverted.
Last time I checked, commits were not free-for-all, but should be done on
Le duodi 12 floréal, an CCXXIV, Carl Eugen Hoyos a écrit :
> Why?
> Does it brake something?
It increases the maintenance burden. Fixing the file itself would have no
such consequence, and make it work with other software too.
Also, could you please fix your mail software so that it does not brea
Hi!
> cane please revert this patch?
Why?
Does it brake something?
> I don't think there's wide support for it.
Two developers seem to wait for an explanation why it should be reverted.
> If we find out more about the origins of the file, we can revisit this
> issue.
I thought the file is
Hi,
On Fri, Apr 29, 2016 at 9:08 AM, Michael Niedermayer wrote:
> On Fri, Apr 29, 2016 at 08:09:34AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Apr 29, 2016 at 7:52 AM, Carl Eugen Hoyos
> wrote:
> >
> > > I was under the impression that the only reason that demuxers and
> decoders
>
On Fri, Apr 29, 2016 at 08:09:34AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Apr 29, 2016 at 7:52 AM, Carl Eugen Hoyos wrote:
>
> > I was under the impression that the only reason that demuxers and decoders
> > are written like that is that we all want FFmpeg to support invalid streams
>
Hi,
On Fri, Apr 29, 2016 at 7:52 AM, Carl Eugen Hoyos wrote:
> I was under the impression that the only reason that demuxers and decoders
> are written like that is that we all want FFmpeg to support invalid streams
> as long as this doesn't affect valid streams.
It's too broad. I want to know
Hi Ronald!
> So, since you're stating this as fact, I would like to point out that this
> was never formally agreed by any group of FFmpeg developers, and this is
> certainly not the official position.
Your message surprises me: The mpegts demuxer (before this discussed patch)
accepts all kind
Hi,
On Thu, Apr 28, 2016 at 3:42 AM, Carl Eugen Hoyos wrote:
> Kieran Kunhya obe.tv> writes:
>
> > > It is very important that FFmpeg also decodes invalid
> > > files as long as no valid files are affected.
> >
> > Nonsense,
>
> > should FFmpeg be able to decode any file created by using netcat
Hi,
2016-04-27 23:58 GMT+02:00 Carl Eugen Hoyos :
> Mark Thompson jkqxz.net> writes:
>
>> Unless someone can show what created this file and that
>> it might make more, I suggest that the hack workaround
>> should be removed.
>
> Is there a valid file affected by the applied patch?
> It is very i
On Thu, 28 Apr 2016 at 08:42 Carl Eugen Hoyos wrote:
> Kieran Kunhya obe.tv> writes:
>
> > > It is very important that FFmpeg also decodes invalid
> > > files as long as no valid files are affected.
> >
> > Nonsense,
>
> > should FFmpeg be able to decode any file created by using netcat
> > on r
Kieran Kunhya obe.tv> writes:
> > It is very important that FFmpeg also decodes invalid
> > files as long as no valid files are affected.
>
> Nonsense,
> should FFmpeg be able to decode any file created by using netcat
> on random RTP data?
> Should FFmpeg be able to decode wireshark dumps wh
On Wed, 27 Apr 2016 at 14:59 Carl Eugen Hoyos wrote:
> Mark Thompson jkqxz.net> writes:
>
> > Unless someone can show what created this file and that
> > it might make more, I suggest that the hack workaround
> > should be removed.
>
> Is there a valid file affected by the applied patch?
> It is
Mark Thompson jkqxz.net> writes:
> Unless someone can show what created this file and that
> it might make more, I suggest that the hack workaround
> should be removed.
Is there a valid file affected by the applied patch?
It is very important that FFmpeg also decodes invalid
files as long as
On Wed, 27 Apr 2016 at 11:32 Mark Thompson wrote:
> On 24/04/16 23:24, Michael Niedermayer wrote:
> > On Sun, Apr 24, 2016 at 11:27:32AM +0100, Mark Thompson wrote:
> >> On 24/04/16 03:53, Michael Niedermayer wrote:
> >>> 0x47 is expected to be at [0] but the affected files contain something
> >>
On 24/04/16 23:24, Michael Niedermayer wrote:
> On Sun, Apr 24, 2016 at 11:27:32AM +0100, Mark Thompson wrote:
>> On 24/04/16 03:53, Michael Niedermayer wrote:
>>> 0x47 is expected to be at [0] but the affected files contain something
>>> else sometimes in its place that starts with 0x80 and is 12
On Sun, Apr 24, 2016 at 11:27:32AM +0100, Mark Thompson wrote:
> On 24/04/16 03:53, Michael Niedermayer wrote:
> > 0x47 is expected to be at [0] but the affected files contain something
> > else sometimes in its place that starts with 0x80 and is 12 bytes long
> > it contains some counter or timest
On 24/04/16 03:53, Michael Niedermayer wrote:
> 0x47 is expected to be at [0] but the affected files contain something
> else sometimes in its place that starts with 0x80 and is 12 bytes long
> it contains some counter or timestamp
> without the code above it will almost always work but if the coun
On Sat, Apr 23, 2016 at 06:09:37PM -0700, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Apr 10, 2016 at 11:12 AM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
> > @@ -2344,6 +2344,12 @@ static int mpegts_resync(AVFormatContext *s, int
> > seekback)
> >
> > avio_seek(pb, -FFMIN(seekba
Hi,
On Sun, Apr 10, 2016 at 11:12 AM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
> @@ -2344,6 +2344,12 @@ static int mpegts_resync(AVFormatContext *s, int
> seekback)
>
> avio_seek(pb, -FFMIN(seekback, pos), SEEK_CUR);
>
> +//Special case for files like 01c56b0dc1.ts
> +if
On Sun, Apr 10, 2016 at 11:13:55PM +0200, Michael Niedermayer wrote:
> On Sun, Apr 10, 2016 at 08:23:58PM +0200, Paul B Mahol wrote:
> > On 4/10/16, Michael Niedermayer wrote:
> > > This fixes demuxing of 01c56b0dc1.ts
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/mp
On Sun, Apr 10, 2016 at 08:23:58PM +0200, Paul B Mahol wrote:
> On 4/10/16, Michael Niedermayer wrote:
> > This fixes demuxing of 01c56b0dc1.ts
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mpegts.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
On 4/10/16, Michael Niedermayer wrote:
> This fixes demuxing of 01c56b0dc1.ts
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mpegts.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index e856ff0..3
This fixes demuxing of 01c56b0dc1.ts
Signed-off-by: Michael Niedermayer
---
libavformat/mpegts.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index e856ff0..38ff264 100644
--- a/libavformat/mpegts.c
+++ b/libavform
27 matches
Mail list logo
