On 8/3/20, Martin Storsjö wrote:
> On Mon, 3 Aug 2020, Paul B Mahol wrote:
>
>> ffmpeg | branch: master | Paul B Mahol | Mon Aug 3
>> 09:33:36 2020 +0200| [05e58ce4e29ea47b2e06888c64055aa2f8d3e76c] |
>> committer: Paul B Mahol
>>
>> avcodec/cfhd: use LUT for 9 and 18 codebook decompanding
>>
>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Guo,
> Yejun
> Sent: Monday, August 3, 2020 10:20 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V3 1/2] dnn/native: add native support for
> avg_pool
>
>
>
> > -Original Message-
Aug 3, 2020, 18:31 by mich...@niedermayer.cc:
> This differs from the MPEG specification as the actual real world
> files do compute their CRC over variable areas and not the fixed
> ones listed in the specification. This is also the reason for
> the complexity of this code and the need to perform
On Thu, 30 Jul 2020, Nicolas George wrote:
Signed-off-by: Nicolas George
---
libavformat/tests/url.c | 34 +++
libavformat/url.c | 74 +
libavformat/url.h | 41 +++
tests/ref/fate/url | 45 ++
On Mon, Aug 03, 2020 at 02:07:36PM +0100, Jack Haughton wrote:
> A NULL check in av_parse_video_rate() would certainly not be a bad idea. It
> wouldn't (on its own) restore the NULL input robustness to
> set_string_video_rate() though, as any error value returned from
> av_parse_video_rate() would
On Sat, Aug 1, 2020 at 2:07 PM Jan Ekström wrote:
>
> The decoding parts of this patch set have not changed from v2.
> I have now added changes so that 22.2 gets properly handled as
> 5.1 (for which it has backwards compatibility) until it gets a
> proper remix matrix defined in swresample. So
>
On Mon, Aug 03, 2020 at 10:38:21PM +0200, Marton Balint wrote:
>
>
> On Sun, 2 Aug 2020, Dave Rice wrote:
>
> >
> >
> > > On Aug 1, 2020, at 5:26 PM, Marton Balint wrote:
> > >
> > >
> > >
> > > On Sat, 1 Aug 2020, Michael Niedermayer wrote:
> > >
> > > > On Sat, Aug 01, 2020 at 07:28:53P
On Mon, 3 Aug 2020, Paul B Mahol wrote:
ffmpeg | branch: master | Paul B Mahol | Mon Aug 3 09:33:36
2020 +0200| [05e58ce4e29ea47b2e06888c64055aa2f8d3e76c] | committer: Paul B Mahol
avcodec/cfhd: use LUT for 9 and 18 codebook decompanding
Also fix codebook 9 decompanding, fixing artifact wit
On Sun, 2 Aug 2020, Martin Storsjö wrote:
On Sunday, August 2, 2020, Andreas Rheinhardt
wrote:
Martin Storsjö:
> Previously, the hls-fmp4 and hls-fmp4_ac3 tests used the same
file
> names for init and segment files, which occasionally could
cause
> corruption
On Mon, 3 Aug 2020, Michael Niedermayer wrote:
On Sun, Aug 02, 2020 at 11:38:51PM +0300, Martin Storsjö wrote:
This parameter artificially throttled the generation of the test sample
to take 5 seconds.
---
tests/fate/hlsenc.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Sun, 2 Aug 2020, Dave Rice wrote:
On Aug 1, 2020, at 5:26 PM, Marton Balint wrote:
On Sat, 1 Aug 2020, Michael Niedermayer wrote:
On Sat, Aug 01, 2020 at 07:28:53PM +0200, Marton Balint wrote:
On Sat, 1 Aug 2020, Michael Niedermayer wrote:
Fixes: Ticket8762
Signed-off-by: Mich
On Sun, Aug 02, 2020 at 11:38:51PM +0300, Martin Storsjö wrote:
> This parameter artificially throttled the generation of the test sample
> to take 5 seconds.
> ---
> tests/fate/hlsenc.mak | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/fate/hlsenc.mak b/tests/fate/
Wow,
That is such an awesome idea.
Did not know about that offsetof() thing earlier. Definitely going to use
this idea.
> IIRC, the Linux kernel makes heavy use of this structure.
>
That's really cool.
Actually I implemented linked lists and not dynamic arrays because some
elements from somewhe
Aug 3, 2020, 15:43 by jamr...@gmail.com:
> Layers 1 and 2 use lengths in bits which are not a multiple of 8,
> and our CRC works on a per-byte basis.
>
> Based on b48397e7b8
>
LGTM, that was a really bad messup on my part.
Thanks.
___
ffmpeg-devel maili
On Mon, 3 Aug 2020 at 10:48, Paul B Mahol wrote:
> Hi,
>
> patch attached.
>
>
Seems fine if tested.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or ema
A NULL check in av_parse_video_rate() would certainly not be a bad idea. It
wouldn't (on its own) restore the NULL input robustness to
set_string_video_rate() though, as any error value returned from
av_parse_video_rate() would result in val being logged using %s, which is
the whole problem that a5
Quoting Kieran Kunhya (2020-08-03 18:36:16)
> On Mon, 3 Aug 2020 at 08:16, Anton Khirnov wrote:
>
> > Quoting Kieran Kunhya (2020-07-27 20:15:17)
> > > On Mon, 27 Jul 2020 at 11:09, Anton Khirnov wrote:
> > >
> > > > Quoting Kieran Kunhya (2020-07-26 01:51:22)
> > > > > Hi,
> > > > >
> > > > > I
> On Aug 3, 2020, at 5:54 PM, Nicolas George wrote:
>
> Nicolas George (12020-07-31):
>> Something like this would be acceptable:
>>
>> /* Reverse-engineered by encoding various files with the reference
>> encoder. */
>>
>> Reluctance to give this little information is baffling to me.
>
>
On Mon, Aug 03, 2020 at 10:47:44AM +0200, Lynne wrote:
> Aug 3, 2020, 01:45 by mich...@niedermayer.cc:
>
> > On Sun, Aug 02, 2020 at 08:52:22PM +, Lynne wrote:
> >
> >> ffmpeg | branch: master | Lynne | Sun Aug 2 22:45:00 2020
> >> +0200| [b48397e7b84864f2d4c70361a4c4bed93e826753] | committ
This differs from the MPEG specification as the actual real world
files do compute their CRC over variable areas and not the fixed
ones listed in the specification. This is also the reason for
the complexity of this code and the need to perform the CRC
check for layer2 in the middle of layer2 decod
On Mon, 3 Aug 2020 at 08:16, Anton Khirnov wrote:
> Quoting Kieran Kunhya (2020-07-27 20:15:17)
> > On Mon, 27 Jul 2020 at 11:09, Anton Khirnov wrote:
> >
> > > Quoting Kieran Kunhya (2020-07-26 01:51:22)
> > > > Hi,
> > > >
> > > > I notice that some encoders adjust the PTS with initial_padding
On Mon, Aug 03, 2020 at 10:43:11AM -0300, James Almer wrote:
> Layers 1 and 2 use lengths in bits which are not a multiple of 8,
> and our CRC works on a per-byte basis.
>
> Based on b48397e7b8
>
> Signed-off-by: James Almer
> ---
> libavcodec/mpegaudiodec_template.c | 2 +-
> 1 file changed, 1
Can other developers give their input on this?
I am not currently a FFmpeg developer, so my opinion might
be less relevant than what others have stated.
I think giving a source for things that are not inherently
obvious, but are part of the code is a good idea. Even if
some tables are well ex
On 30/07/2020 16:55, Matthew Szatmary wrote:
>> This seems to be really MP4 centric. Did you check if such patch sent out
>> for RFC in 2018 could do it?
>>
>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/1522179841-34881-2-git-send-email-derek.buitenh...@gmail.com/
>>
> I was unaware of this
Kartik K. Khullar (12020-08-03):
> > Mixing linked lists and indices is usually a sign you are doing
> > something wrong.
> >
> > Here, I believe you would do better with a doubly linked list and
> > pointers instead of indices.
> >
> > Note: there is a trick with doubly linked lists where you put
On 8/3/2020 10:45 AM, Lynne wrote:
> Aug 3, 2020, 15:43 by jamr...@gmail.com:
>
>> Layers 1 and 2 use lengths in bits which are not a multiple of 8,
>> and our CRC works on a per-byte basis.
>>
>> Based on b48397e7b8
>>
>
> LGTM, that was a really bad messup on my part.
> Thanks.
Will apply. Tha
On 8/3/2020 10:26 AM, James Almer wrote:
> On 8/3/2020 9:45 AM, Michael Niedermayer wrote:
>> On Mon, Aug 03, 2020 at 09:54:41AM +0300, Martin Storsjö wrote:
>>> ---
>>> tests/ref/fate/h264-skip-nointra | 86
>>> tests/ref/fate/h264-skip-nokey | 86 ++
Layers 1 and 2 use lengths in bits which are not a multiple of 8,
and our CRC works on a per-byte basis.
Based on b48397e7b8
Signed-off-by: James Almer
---
libavcodec/mpegaudiodec_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpegaudiodec_template.c
On 8/3/2020 9:45 AM, Michael Niedermayer wrote:
> On Mon, Aug 03, 2020 at 09:54:41AM +0300, Martin Storsjö wrote:
>> ---
>> tests/ref/fate/h264-skip-nointra | 86
>> tests/ref/fate/h264-skip-nokey | 86
>> 2 files changed, 86 inse
On 8/3/2020 7:25 AM, Paul B Mahol wrote:
> On 8/3/20, James Almer wrote:
>> On 8/2/2020 8:43 PM, James Almer wrote:
>>> Will prevet FATE from breaking once LIBAVCODEC_VERSION_MINOR is bumped to
>>> 100.
>>>
>>> Reported-by: zane
>>> Signed-off-by: James Almer
>>> ---
>>> If anyone wants to check
Aug 3, 2020, 01:45 by mich...@niedermayer.cc:
> On Sun, Aug 02, 2020 at 08:52:22PM +, Lynne wrote:
>
>> ffmpeg | branch: master | Lynne | Sun Aug 2 22:45:00 2020
>> +0200| [b48397e7b84864f2d4c70361a4c4bed93e826753] | committer: Lynne
>>
>> mpegaudiodec_template: disable CRC checking for lay
On Mon, Aug 03, 2020 at 09:54:41AM +0300, Martin Storsjö wrote:
> ---
> tests/ref/fate/h264-skip-nointra | 86
> tests/ref/fate/h264-skip-nokey | 86
> 2 files changed, 86 insertions(+), 86 deletions(-)
b48397e7b84864f2d4c70361a4
Aug 3, 2020, 08:58 by mar...@martin.st:
> On Sun, 2 Aug 2020, Lynne wrote:
>
>> ffmpeg | branch: master | Lynne | Sun Aug 2 22:45:00 2020
>> +0200| [b48397e7b84864f2d4c70361a4c4bed93e826753] | committer: Lynne
>>
>> mpegaudiodec_template: disable CRC checking for layers 1 and 2
>>
>> Layers 1 a
On Mon, Aug 3, 2020 at 8:00 PM myp...@gmail.com wrote:
>
> On Mon, Aug 3, 2020 at 2:54 PM Martin Storsjö wrote:
> >
> > ---
> > tests/ref/fate/h264-skip-nointra | 86
> > tests/ref/fate/h264-skip-nokey | 86
> > 2 files changed,
On Mon, Aug 3, 2020 at 2:54 PM Martin Storsjö wrote:
>
> ---
> tests/ref/fate/h264-skip-nointra | 86
> tests/ref/fate/h264-skip-nokey | 86
> 2 files changed, 86 insertions(+), 86 deletions(-)
>
> diff --git a/tests/ref/fate/h26
On Mon, 3 Aug 2020 at 09:18, Anton Khirnov wrote:
> Quoting Kieran Kunhya (2020-07-16 21:32:34)
> > During glitching or looping streams, old frames remain in the DPB.
> > The decoder incorrectly thinks that the DPB contains the right number of
> > buffered frames to output and reordering breaks b
It can be tested with the model generated with below python script:
import tensorflow as tf
import os
import numpy as np
import imageio
from tensorflow.python.framework import graph_util
name = 'ceil'
pb_file_path = os.getcwd()
if not os.path.exists(pb_file_path+'/{}_savemodel/'.format(name)):
On 8/3/20, James Almer wrote:
> On 8/2/2020 8:43 PM, James Almer wrote:
>> Will prevet FATE from breaking once LIBAVCODEC_VERSION_MINOR is bumped to
>> 100.
>>
>> Reported-by: zane
>> Signed-off-by: James Almer
>> ---
>> If anyone wants to check why adding LIBAVCODEC_IDENT to the bitstream (or
>>
On Mon, Aug 3, 2020 at 10:34 AM Carl Eugen Hoyos wrote:
>
>
>
> > Am 02.08.2020 um 23:16 schrieb Jan Ekström :
> >
> >> On Sat, Aug 1, 2020 at 4:29 PM Carl Eugen Hoyos wrote:
> >>
> >>> Am Sa., 1. Aug. 2020 um 14:47 Uhr schrieb Jan Ekström :
> >>>
> On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen
Nicolas George (12020-07-31):
> Something like this would be acceptable:
>
> /* Reverse-engineered by encoding various files with the reference
>encoder. */
>
> Reluctance to give this little information is baffling to me.
Can other developers give their input on this?
Is it acceptable or t
Hi,
patch attached.
0001-avcodec-cfhd-use-LUT-for-9-and-18-codebook-decompand.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
A common pattern e.g. in libavcodec is replacing/updating buffer
references: unref old one, ref new one. This function allows simplifying
such code an avoiding unnecessary refs+unrefs if the references are
already equivalent.
---
Updated to not touch dst on failure.
Still not using buffer_replace(
On Mon, Aug 3, 2020 at 9:34 AM Carl Eugen Hoyos wrote:
>
>
>
> > Am 02.08.2020 um 23:16 schrieb Jan Ekström :
> >
> >> On Sat, Aug 1, 2020 at 4:29 PM Carl Eugen Hoyos wrote:
> >>
> >>> Am Sa., 1. Aug. 2020 um 14:47 Uhr schrieb Jan Ekström :
> >>>
> On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen H
On Mon, 3 Aug 2020, Lynne wrote:
Aug 3, 2020, 08:58 by mar...@martin.st:
This change broke two fate tests; fate-h264-skip-nokey and
fate-h264-skip-nointra. The change does look sensible in itself though
(framecrcs that used to be all zeros now have nonzero, varying values).
Someone must h
Quoting Kieran Kunhya (2020-07-16 21:32:34)
> During glitching or looping streams, old frames remain in the DPB.
> The decoder incorrectly thinks that the DPB contains the right number of
> buffered frames to output and reordering breaks badly
>
> Any non-cosmetic comments welcome.
>From 23f027209
> Am 02.08.2020 um 23:16 schrieb Jan Ekström :
>
>> On Sat, Aug 1, 2020 at 4:29 PM Carl Eugen Hoyos wrote:
>>
>>> Am Sa., 1. Aug. 2020 um 14:47 Uhr schrieb Jan Ekström :
>>>
On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
> Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan
Quoting Kieran Kunhya (2020-07-27 20:15:17)
> On Mon, 27 Jul 2020 at 11:09, Anton Khirnov wrote:
>
> > Quoting Kieran Kunhya (2020-07-26 01:51:22)
> > > Hi,
> > >
> > > I notice that some encoders adjust the PTS with initial_padding and some
> > > don't.
> > > Is this intentional and should we de
47 matches
Mail list logo
