According to ITU-T H.265 7.4.2.1 this byte sequence should not appear in a
NAL unit but in practice in rare cases it seems it does, possibly due to buggy
encoders. Other players like VLC and Quicktime seem to be fine with it.
Currently when this sequence is found it is treated as if the next
According to ITU-T H.265 7.4.2.1 this byte sequence should not appear in a
NAL unit but in practice in rare cases it seems it does, possibly due to buggy
encoders. Other players like VLC and Quicktime seem to be fine with it.
Currently when this sequence is found it is treated as if the next
On Tue, Sep 13, 2022 at 11:28 AM Paul B Mahol wrote:
> On 9/8/22, Paul B Mahol wrote:
> > Patch attached.
> >
>
> Will apply soon.
Curious where the 1 << 28 constant come from?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Mon, Sep 5, 2022 at 8:16 PM Paul B Mahol wrote:
> Patch attached.
>
Thanks and can confirm that the patch produces the same samples as the flac
reference decoder for the original file in
https://trac.ffmpeg.org/ticket/9621 that I could not share.
But I'm not sure I follow how the patch
On Tue, Sep 6, 2022 at 3:45 PM Martin Storsjö wrote:
> On Tue, 6 Sep 2022, Mattias Wadman wrote:
>
> > On Sat, Sep 3, 2022 at 3:41 AM Lynne wrote:
> >
> >> Needed for the next patch.
> >> We get this for the extremely small cost of a branch on _ns functions
On Sat, Sep 3, 2022 at 3:41 AM Lynne wrote:
> Needed for the next patch.
> We get this for the extremely small cost of a branch on _ns functions,
> which wouldn't be used anyway with assembly.
>
> Patch attached.
>
Hi, I have issues building on macOS (12.5.1) with this patch. Maybe I'm
missing
---
libavfilter/vf_zscale.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 91166dcbcb..999147b587 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -1033,6 +1033,7 @@ static const AVOption
On Thu, Oct 21, 2021 at 10:35 PM Michael Niedermayer
wrote:
> On Thu, Oct 21, 2021 at 10:17:25PM +0200, Paul B Mahol wrote:
> > LGTM for now
>
> will apply the improved variant below
>
> diff --git a/libavcodec/flac_parser.c b/libavcodec/flac_parser.c
> index 2c550507fc8..3b27b152fc5 100644
>
On Wed, Oct 20, 2021 at 11:07 PM Michael Niedermayer
wrote:
> On Wed, Oct 13, 2021 at 06:15:26PM +0200, Mattias Wadman wrote:
> > Reduces the risk of finding false frames that happens to have valid
> values and CRC.
> >
> > Fixes ticket #9185 ffmpeg flac decoder inco
Thanks for taking your time to review
On Mon, Oct 18, 2021 at 5:16 PM Paul B Mahol wrote:
> LGTM, will apply soon
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit
On Wed, Oct 13, 2021 at 6:15 PM Mattias Wadman
wrote:
> Reduces the risk of finding false frames that happens to have valid values
> and CRC.
>
> Fixes ticket #9185 ffmpeg flac decoder incorrectly finds junk frame
> https://trac.ffmpeg.org/ticket/9185
> ---
> libavcod
Reduces the risk of finding false frames that happens to have valid values and
CRC.
Fixes ticket #9185 ffmpeg flac decoder incorrectly finds junk frame
https://trac.ffmpeg.org/ticket/9185
---
libavcodec/flac_parser.c | 30 --
1 file changed, 28 insertions(+), 2
On Fri, Jul 16, 2021 at 9:51 AM Thilo Borgmann
wrote:
> Am 04.07.21 um 21:23 schrieb Michael Niedermayer:
> > On Sun, Jun 20, 2021 at 09:48:29PM +0200, Thilo Borgmann wrote:
> >> Hi,
> >>
> >> adds a new variant to the -force_key_frames option "source_no_drop" to
> make
> >> sure whenever a key
On Mon, Jul 6, 2020 at 5:59 PM Olly Woodman wrote:
>
> On Mon, 6 Jul 2020 at 05:54, Jim DeLaHunt wrote:
>
> > On 2020-07-04 07:43, Nicolas George wrote:
> > > [In the FFmpeg project,] [t]here is work in making highly-optimized
> > > decoders, this work is impressive and creative…. But as far as
Hello, ok to merge?
On Tue, May 19, 2020 at 11:27 AM Mattias Wadman
wrote:
>
> Some flac muxers write truncated metadata picture size if the picture
> data do not fit in 24 bits. Detect this by truncting the size found inside
> the picture block and if it matches the block size use
On Sat, May 23, 2020 at 2:23 AM wrote:
>
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/ffmpeg.texi | 15
> fftools/ffmpeg.h| 2 ++
> fftools/ffmpeg_filter.c | 20
> fftools/ffmpeg_opt.c| 20
>
Some flac muxers write truncated metadata picture size if the picture
data do not fit in 24 bits. Detect this by truncting the size found inside
the picture block and if it matches the block size use it and read rest
of picture data.
This workaround is only for flac files and not ogg files with
On Sat, May 16, 2020 at 9:59 PM Andreas Rheinhardt
wrote:
>
> Mattias Wadman:
> > lavf flacenc could previously write truncated metadata picture size if
> > the picture data did not fit in 24 bits. Detect this by truncting the
> > size found inside the picture block and
Some flac muxers write truncated metadata picture size if the picture
data do not fit in 24 bits. Detect this by truncting the size found inside
the picture block and if it matches the block size use it and read rest
of picture data.
Used to be an issue with lavf flacenc that was fixed in
Hi, any chance to get this merged?
On Sun, May 3, 2020 at 12:32 PM Mattias Wadman wrote:
>
> Sorry for nagging, something left to fix?
>
> On Mon, Apr 27, 2020 at 10:10 AM Mattias Wadman
> wrote:
> >
> > Hi again, looks ok?
> >
> > On Fri, Apr 24, 202
Sorry for nagging, something left to fix?
On Mon, Apr 27, 2020 at 10:10 AM Mattias Wadman
wrote:
>
> Hi again, looks ok?
>
> On Fri, Apr 24, 2020 at 12:54 PM Mattias Wadman
> wrote:
> >
> > lavf flacenc could previously write truncated metadata picture size if
>
On Tue, Apr 28, 2020 at 4:45 PM Lynne wrote:
>
> Apr 28, 2020, 15:31 by mattias.wad...@gmail.com:
>
> > Nice, test files works fine now
> >
> > Would it make sense to conditionally ignore crc mismatch based on
> > s->error_recognition & AV_EF_CRCCHECK ?
> >
>
> I don't think so. This container
On Tue, Apr 28, 2020 at 4:12 PM Lynne wrote:
>
> Apr 28, 2020, 14:05 by mattias.wad...@gmail.com:
>
> > On Tue, Apr 28, 2020 at 1:59 PM Lynne wrote:
> >
> >>
> >> This makes decoding far more robust, since OggS, the ogg magic,
> >> can be commonly found randomly in streams, which previously made
On Tue, Apr 28, 2020 at 1:59 PM Lynne wrote:
>
> This makes decoding far more robust, since OggS, the ogg magic,
> can be commonly found randomly in streams, which previously made
> the demuxer think there's a new stream or a change in such.
>
> Patch attached.
Maybe nitpick, could seek back
On Tue, Apr 28, 2020 at 1:59 PM Lynne wrote:
>
> This makes decoding far more robust, since OggS, the ogg magic,
> can be commonly found randomly in streams, which previously made
> the demuxer think there's a new stream or a change in such.
>
> Patch attached.
Should check version after
On Tue, Apr 28, 2020 at 2:01 PM Lynne wrote:
>
> Apr 27, 2020, 21:55 by mich...@niedermayer.cc:
>
> > On Mon, Apr 27, 2020 at 05:19:49PM +0200, Mattias Wadman wrote:
> >
> >> Fixes seek issue with ogg files that have segment data that happens to be
> >>
On Tue, Apr 28, 2020 at 1:06 PM Mattias Wadman wrote:
>
> Fixes seek issue with ogg files that have segment data that happens to be
> encoded as a "OggS" page syncword. Very unlikely but seems to happen.
>
> Have been observed to happen with ffmpeg+libvorbis and oggenc en
Fixes seek issue with ogg files that have segment data that happens to be
encoded as a "OggS" page syncword. Very unlikely but seems to happen.
Have been observed to happen with ffmpeg+libvorbis and oggenc encoding
to 441khz stereo at 160kbps.
---
libavformat/oggdec.c | 136
Fixes seek issue with ogg files that have segment data that happens to be
encoded as a "OggS" page syncword. Very unlikely but seems to happen.
Have been observed to happen with ffmpeg+libvorbis and oggenc encoding
to 441khz stereo at 160kbps.
---
libavformat/oggdec.c | 96
Hi again, looks ok?
On Fri, Apr 24, 2020 at 12:54 PM Mattias Wadman
wrote:
>
> lavf flacenc could previously write truncated metadata picture size if
> the picture data did not fit in 24 bits. Detect this by truncting the
> size found inside the picture block and if it matches th
On Fri, Apr 24, 2020 at 12:41 PM Mattias Wadman
wrote:
>
> lavf flacenc could previously write truncated metadata picture size if
> the picture data did not fit in 24 bits. Detect this by truncting the
> size found inside the picture block and if it matches the block size
> use i
lavf flacenc could previously write truncated metadata picture size if
the picture data did not fit in 24 bits. Detect this by truncting the
size found inside the picture block and if it matches the block size
use it and read rest of picture data.
Also only enable this workaround flac files and
lavf flacenc could previously write truncated metadata picture size if
the picture data did not fit in 24 bits. Detect this by truncting the
size found inside the picture block and if it matches the block size
use it and read rest of picture data.
Also only enable this workaround flac files and
On Fri, Apr 24, 2020 at 11:26 AM Andreas Rheinhardt
wrote:
>
> Mattias Wadman:
> > On Fri, Apr 24, 2020 at 7:29 AM Andreas Rheinhardt
> > wrote:
> >>
> >> Mattias Wadman:
> >>> lavf flacenc could previously write truncated metadata picture size
On Fri, Apr 24, 2020 at 7:29 AM Andreas Rheinhardt
wrote:
>
> Mattias Wadman:
> > lavf flacenc could previously write truncated metadata picture size if
> > the picture data did not fit in 24 bits. Detect this by truncting the
> > size found inside the picture block and
On Thu, Apr 23, 2020 at 5:15 PM Mattias Wadman wrote:
>
> lavf flacenc could previously write truncated metadata picture size if
> the picture data did not fit in 24 bits. Detect this by truncting the
> size found inside the picture block and if it matches the block size
> use i
lavf flacenc could previously write truncated metadata picture size if
the picture data did not fit in 24 bits. Detect this by truncting the
size found inside the picture block and if it matches the block size
use it and read rest of picture data.
Also only enable this workaround flac files and
On Wed, Apr 22, 2020 at 5:18 PM Andreas Rheinhardt
wrote:
>
> Mattias Wadman:
> > lavf flacenc could previously write truncated metadata picture size if
> > the picture data did not fit in 24 bits. Detect this by truncting the
> > size found inside the picture block and
lavf flacenc could previously write truncated metadata picture size if
the picture data did not fit in 24 bits. Detect this by truncting the
size found inside the picture block and if it matches the block size
use it and read rest of picture data.
flacenc was fixed in
Hoyos
wrote:
> Am Sa., 11. Apr. 2020 um 11:53 Uhr schrieb Mattias Wadman
> :
> >
> > Regression since 8d3630c5402fdda2889fe4f74f7dcdd50ebca654 where keys
> were changed
> > to not be touppered but the picture block strcmp was not changed to be
> case-insensi
Regression since 8d3630c5402fdda2889fe4f74f7dcdd50ebca654 where keys were
changed
to not be touppered but the picture block strcmp was not changed to be
case-insensitive.
---
libavformat/oggparsevorbis.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Sorry i failed to get gmail to play nice with patches :( sent a new
message using git send-email, hope that works.
On Wed, Oct 30, 2019 at 12:51 PM Michael Niedermayer
wrote:
>
> On Tue, Oct 29, 2019 at 02:42:47PM +0100, Mattias Wadman wrote:
> > A too big picture will case the mu
attached_pic -t 1 test.flac
Try to decode:
ffmpeg -i test.flac test.wav
Signed-off-by: Mattias Wadman
---
libavformat/flacenc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index 93cc79bbe0..7b51c11404 100644
Mattias Wadman (1):
libavformat/flacenc: reject too big picture blocks
libavformat/flacenc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
attached_pic -t 1 test.flac
Try to decode:
ffmpeg -i test.flac test.wav
Signed-off-by: Mattias Wadman
---
libavformat/flacenc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index 93cc79bbe0..7b51c11404 100644
Think i messed up the formatting of the in-line patch somehow. Ill send the
patch as an attachment instead. Hope reply and attach is ok?
On Sun, Oct 27, 2019 at 8:22 PM Mattias Wadman
wrote:
> A too big picture will case the muxer to write a truncated block size
> (uint24)
> causing t
attached_pic -t 1 test.flac
Try to decode:
ffmpeg -i test.flac test.wav
Signed-off-by: Mattias Wadman
---
libavformat/flacenc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git libavformat/flacenc.c libavformat/flacenc.c
index 93cc79bbe0..957bcb1123 100644
--- libavformat
47 matches
Mail list logo
