On Fri, 2021-07-09 at 11:32 +0800, Fei Wang wrote:
> Since order_hint_bits_minus_1 range is 0~7, cur_frame_hint can be
> most 128. And similar return value for cbs_av1_get_relative_dist.
> So if plus them and use int8_t for the result may lose its precision.
>
> Signed-off-by: Fei Wang
> ---
> l
8 Jul 2021, 22:32 by stefa...@gmail.com:
> On Mon, Jun 28, 2021 at 2:50 AM Lynne wrote:
>
>>
>> 27 Jun 2021, 19:33 by kier...@obe.tv:
>>
>> >>
>> >> I'm thinking of getting a:
>> >> LG UltraGear 27GN950-B
>> >>
>> >
>> > Can I ask why you need a ~£1000 monitor? What does it do that others can't?
On Thu, Jul 08, 2021 at 12:40:26PM +0200, Michael Niedermayer wrote:
> Fixes: null pointer dereference
> Fixes: alloc_slice.mp4
>
> Found-by: Rafael Dutra
> Signed-off-by: Michael Niedermayer
> ---
> libswscale/slice.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
will apply
[...
On Thu, Jul 08, 2021 at 01:22:44PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libswscale/output.c | 11 +++
> 1 file changed, 11 insertions(+)
will apply patchset
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let u
On Mon, Jul 05, 2021 at 10:24:54PM +0200, Michael Niedermayer wrote:
> Fixes: NULL pointer dereference
> Fixes: decode_spectrum_and_dequant.mp4
>
> Found-by: Rafael Dutra
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/aacdec_template.c | 7 ++-
> 1 file changed, 6 insertions(+), 1
On 7/9/2021 12:32 AM, Fei Wang wrote:
Make it flexible if decode frame(without apply film grain) and display
frame(applied film grain) both needed when decode film grain clips.
Why do you need to do this for Vaapi? Nvdec doesn't require it, it just
ensures to reference one of the extra eight s
This allows the decoder context to be initialized with all stream parameters
before a packet is parsed.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 45 +++
1 file changed, 45 insertions(+)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1
Maximum size of a MOV chunk should be taken from the configurable
max_chunk_size option in AVFormatContext. If it is not defined revert to
the previously set limit of 1mb.
This patch was made in order to control the size of chunks in a MOV format
writer. I noticed that there was already an option
This patch ensures that MSVC builds under msys will use windres when
available, thereby resulting in the appropriate version and copyright
information to be included in the dlls, as is already the case in the mingw
builds.
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure
On 7/9/2021 4:02 PM, Matthias C. M. Troffaes wrote:
This patch ensures that MSVC builds under msys will use windres when
available, thereby resulting in the appropriate version and copyright
information to be included in the dlls, as is already the case in the mingw
builds.
Wouldn't it make mor
On Fri, Jul 9, 2021 at 9:27 PM James Almer wrote:
> Wouldn't it make more sense to add support for rc.exe instead?
Yes, that's an excellent point, and I agree that would be better.
Additionally, I've just found the patch breaks the build on some libraries
(at least postproc), my apologies for m
Hi,
I am working on porting a Kodi player to an NVidia Jetson Nano device. I've
been developing a decoder for quite some time now, and realized that the
best approach would be to have it inside of ffmpeg, instead of embedding
the decoder into Kodi as it heavily relies on FFMPEG. Just wondering if
On Saturday, 10 July 2021 8:53:27 AM AEST Andrii wrote:
> I am working on porting a Kodi player to an NVidia Jetson Nano device. I've
> been developing a decoder for quite some time now, and realized that the
> best approach would be to have it inside of ffmpeg, instead of embedding
> the decoder i
On 10.07.2021 00:53, Andrii wrote:
Hi,
I am working on porting a Kodi player to an NVidia Jetson Nano device. I've
been developing a decoder for quite some time now, and realized that the
best approach would be to have it inside of ffmpeg, instead of embedding
the decoder into Kodi as it heavily
After fixing AV_PKT_DATA_SKIP_SAMPLES for reading vorbis packets from ogg,
the actual decoded samples become fewer. Three fate tests are failing:
fate-vorbis-20:
The samples in 6.ogg are not frame aligned. 6.pcm file was generated by
ffmpeg before the fix. After the fix, the decoded pcm file does
On Thu, Jul 8, 2021 at 3:42 AM Lynne wrote:
>
> 7 Jul 2021, 17:41 by sunguangy...@gmail.com:
>
> > After fixing AV_PKT_DATA_SKIP_SAMPLES for reading vorbis packets from ogg,
> > the actual decoded samples become fewer. Three fate tests are failing:
> >
> > fate-vorbis-20:
> > The samples in 6.ogg
Frame size of Opus stream was previously presumed here to be 960 samples
(20ms), however sizes of 120, 240, 480, 1920, and 2880 are also allowed.
It can also alter on a per-packet basis and even multiple frames may be
present in a single packet according to the specification, for the sake
of simpli
17 matches
Mail list logo
