A few minor tweaks to libavutil/film_grain_params.c.
Leo Izen (2):
avutil/film_grain_params: remove unused variables
avutil/film_grain_params: remove do loop in CHECK macro
libavutil/film_grain_params.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
--
2.44.0
There seems to be a couple of documentation conventions in the code:
/**
* - encoding: (who sets this in encoding context)
* - decoding: (who sets this in decoding context)
*/
int foo;
/**
* Encoding: (meaning in encoding context)
* Decoding: (meaning in decoding context)
This is the scenario:
- unaligned PES and NAL encoding
- the first NAL of the access unit begins at the very end of a ts packet,
sometimes only the 0x00 of the trailing byte (unfortunately, this is still
conformant to the standards!)
- the video frame is so small (ex: typically still picture) it
On Wed, Feb 7, 2024 at 6:40 PM Vittorio Giovara
wrote:
> On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote:
>
> > Anton Khirnov (12024-02-07):
> > > ...so they are precisely broken by design.
> >
> > Words words words.
> >
> > Words to try and hide that something used to work for people and
On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote:
> Anton Khirnov (12024-02-07):
> > ...so they are precisely broken by design.
>
> Words words words.
>
> Words to try and hide that something used to work for people and now you
> are done with it it no longer works.
>
> Exactly the kind of
Anton Khirnov (12024-02-07):
> ...so they are precisely broken by design.
Words words words.
Words to try and hide that something used to work for people and now you
are done with it it no longer works.
Exactly the kind of attitude that killed libav, killing FFmpeg now.
--
Nicolas George
Quoting Stefano Sabatini (2024-02-05 01:02:20)
> This implies a misunderstanding of what these components are. If
> they are broken with ffmpeg.c this is not a good reason to remove
> them (ffmpeg.c is not the only user).
They are broken with _any_ caller that happens to call libavformat from
a
Anton Khirnov (12024-02-07):
> For instance? What do these devices support that e.g. NUT does not?
Returning the latency of the device.
> neither should we try.
This is the libav mindset we do not want in FFmpeg.
--
Nicolas George
___
ffmpeg-devel
It works until move or resize the window.
yes, that's right. I didn't notice because I didn't try to move or resize the
window.
My point is: Removing SDL would break many examples that can be found in the
internet.
Michael
___
ffmpeg-devel
Quoting Marton Balint (2024-02-04 11:11:12)
> > The 'pipe:' output can be used with a real video player such as mpv, vlc, or
> > even ffplay. For cases where the user was an application using the API they
> > should supply their own renderer.
>
> Yeah, but I never liked when people piped
> On Feb 7, 2024, at 04:51, Michael Koch wrote:
>
> I didn't notice any problems with -f sdl2. I just tested again with Windows
> 11 and the latest FFmpeg build from Gyan, just 2 days old.
>
> ffmpeg -re -f lavfi -i testsrc2=s=800x600 -t 10 -f sdl2 -
>
> Works without any problems.
It
I didn't notice any problems with -f sdl2. I just tested again with
Windows 11 and the latest FFmpeg build from Gyan, just 2 days old.
ffmpeg -re -f lavfi -i testsrc2=s=800x600 -t 10 -f sdl2 -
Works without any problems.
Michael
___
ffmpeg-devel
On Tue, Feb 6, 2024 at 9:08 AM Michael Koch
wrote:
> Removing SDL2 sounds like a very bad idea. There are many examples which
> are using these output devices, and all these examples would be broken.
> A quick search in my book
> http://www.astro-electronic.de/FFmpeg_Book.pdf
> finds about 40
Zhao Zhili (12024-02-06):
> Those examples are broken already before the patch.
Funny that the people who actually use the feature had not noticed.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
> On Feb 6, 2024, at 16:08, Michael Koch wrote:
>
> Removing SDL2 sounds like a very bad idea. There are many examples which are
> using these output devices, and all these examples would be broken. A quick
> search in my book
> http://www.astro-electronic.de/FFmpeg_Book.pdf
> finds about
Removing SDL2 sounds like a very bad idea. There are many examples which
are using these output devices, and all these examples would be broken.
A quick search in my book
http://www.astro-electronic.de/FFmpeg_Book.pdf
finds about 40 occurences for "-f sdl" or "-f sdl2".
Michael
On date Sunday 2024-02-04 10:02:31 +0100, J. Dekker wrote:
> With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> the
> 'main' thread. This means that both the SDL2 and OpenGL output device are
> broken
> in master. Rather than attempting to fix it, they should be
On Sun, 4 Feb 2024, Rémi Denis-Courmont wrote:
Le 4 février 2024 11:11:12 GMT+01:00, Marton Balint a écrit :
Actually they work here on a linux box with OpenSuse 15.5. So even if they
are broken on some setups, they are not broken everywhere, or not more broken
than they used to be.
On Sun, Feb 04, 2024 at 10:02:31AM +0100, J. Dekker wrote:
> With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> the
> 'main' thread. This means that both the SDL2 and OpenGL output device are
> broken
> in master. Rather than attempting to fix it, they should be
Le 4 février 2024 10:02:31 GMT+01:00, "J. Dekker" a écrit :
>With the addition of threading in ffmpeg.c, the SDL2 devices no longer have the
>'main' thread. This means that both the SDL2 and OpenGL output device are
>broken
>in master. Rather than attempting to fix it, they should be removed
Le 4 février 2024 11:11:12 GMT+01:00, Marton Balint a écrit :
>Actually they work here on a linux box with OpenSuse 15.5. So even if they
>are broken on some setups, they are not broken everywhere, or not more broken
>than they used to be.
No. They were always broken in terms of the design,
On Sun, 4 Feb 2024, J. Dekker wrote:
With the addition of threading in ffmpeg.c, the SDL2 devices no longer have the
'main' thread. This means that both the SDL2 and OpenGL output device are broken
in master. Rather than attempting to fix it, they should be removed instead as
there are
FFmpeg project leader never left, it is still Michael.
But now there are his minions like Anton and others.
FFmpeg is already dead project.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
Quoting Zhao Zhili (2024-02-04 10:19:11)
> > On Feb 4, 2024, at 17:02, J. Dekker wrote:
> >
> > With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> > the
> > 'main' thread. This means that both the SDL2 and OpenGL output device are
> > broken
> > in master. Rather
Quoting J. Dekker (2024-02-04 10:02:31)
> With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> the
> 'main' thread. This means that both the SDL2 and OpenGL output device are
> broken
> in master. Rather than attempting to fix it, they should be removed instead as
>
> On Feb 4, 2024, at 17:02, J. Dekker wrote:
>
> With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> the
> 'main' thread. This means that both the SDL2 and OpenGL output device are
> broken
> in master. Rather than attempting to fix it, they should be removed
With the addition of threading in ffmpeg.c, the SDL2 devices no longer have the
'main' thread. This means that both the SDL2 and OpenGL output device are broken
in master. Rather than attempting to fix it, they should be removed instead as
there are better alternatives for debugging or viewing
This adds support for cLLi and mDVc chunks in the PNG specification[1].
[1]: https://www.w3.org/TR/png-3/
Leo Izen (2):
avcodec/pngdec: read cLLi and mDVc chunks
avcodec/pngenc: write cLLi and mDVc chunks
libavcodec/pngdec.c | 63 +
Synchronize video frames with an external mapping from a file.
Follows up on the idea in
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305986.html
implemented as a filter.
Not storing the frame map in a probably huge string but buffering
piece-wise. Using a fixed format string.
Two bug fixes related to the JPEG XL parser. They're not exactly related and
don't need to be applied in sequence.
Leo Izen (2):
avcodec/jpegxl_parse{,r}: use correct ISOBMFF extended size location
avcodec/jpegxl_parser: fix parsing sequences of extremely small files
First time modifing FFmpeg code and sending patch, please bear with me for
mistakes.
Following patches add support for applying 3D LUT from file using oneVPL VPP.
Limitation:
The new feature is only available when `CONFIG_VAAPI` is enabled, because of
my limited test environemnt and little
Preparatory patch independently beneficial. Note: all of these
are for the sake of simplicity, from 2020, but needed cleaner
rebasing.
Christophe Gisquet (2):
Expose and start using skip_remaining
read_xbits: request fewer bits
libavcodec/bitstream.h | 8 +---
This set contains 2 additions to the patch review and commit policy/guidlines
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
AviSynth+ 3.7.3 adds the ability to define audio
channel layouts, and adding it to the libavformat
demuxer is trivial.
Bumps the minimum required version of the AviSynth+
headers to 3.7.3.
Stephen Hutchinson (2):
avisynth: pass audio channel layout
configure: bump minimum AviSynth+ header
Hi Marton,
Sorry, I'm now recognizing I should have answered this email prior to
the later one. Comments inline:
On Tue, Apr 25, 2023 at 5:59 PM Marton Balint wrote:
> > Regarding the use of avpriv_packet_list() as opposed to
> > avpacket_queue_*, I used the avpacket_queue functions for
Hello Marton,
On Wed, Apr 26, 2023 at 3:36 AM Marton Balint wrote:
> Okay, I realized there is one thing here I don't understand. What if we
> interleave data packets the same way as others, but we don't wait for them
> in order to start flushing packet queues?
>
> So I wonder, if you removed
On Mon, 24 Apr 2023, Devin Heitmueller wrote:
Hello Marton,
Thanks for reviewing. Comments inline:
On Sun, Apr 23, 2023 at 2:43 PM Marton Balint wrote:
In general, queueing packets in specific components should be avoided if
possible. Muxed packets are normally ordered by DTS and stream
On Mon, 24 Apr 2023, Devin Heitmueller wrote:
Hello Marton,
Thanks for reviewing. Comments inline:
On Sun, Apr 23, 2023 at 2:43 PM Marton Balint wrote:
[...]
Thanks for the detailed explanations. I guess then keeping the queue is
well justified here.
Regarding the use of
Hello Marton,
Thanks for reviewing. Comments inline:
On Sun, Apr 23, 2023 at 2:43 PM Marton Balint wrote:
> In general, queueing packets in specific components should be avoided if
> possible. Muxed packets are normally ordered by DTS and stream id, generic
> code ensures that. If you want
On Fri, 21 Apr 2023, Devin Heitmueller wrote:
This patch series implements output of SMPTE 2038 VANC over SDI, building
on the prior patch series which added it in the TS domain. Note that
we moved the AVPacketQueue to be common code within libavdevice so it
can be shared by both the
This patch series implements output of SMPTE 2038 VANC over SDI, building
on the prior patch series which added it in the TS domain. Note that
we moved the AVPacketQueue to be common code within libavdevice so it
can be shared by both the decklink input and output.
Comments/feedback are welcome.
On 3/3/23 15:31, Leo Izen wrote:
This patch adds support for animated JPEG XL files in both the libjxl
decoder wrapper and a separate demuxer to properly set the timebase for it.
Leo Izen (2):
avcodec/libjxldec: add animated decode support
avformat/jpegxl_anim_dec: add animated JPEG XL
This patch adds support for animated JPEG XL files in both the libjxl
decoder wrapper and a separate demuxer to properly set the timebase for it.
Leo Izen (2):
avcodec/libjxldec: add animated decode support
avformat/jpegxl_anim_dec: add animated JPEG XL demuxer
MAINTAINERS
The first patch fixes a FATE issue.
The second patch was discussed on IRC. I got a LGTM from Kasper, but sending to
ML here and applying in a few days if there's no objections.
A few things discussed:
1) There's no need to expose the gamma table as another function as it's only
used here.
2)
Add support to the PNG decoder and encoder to support sBIT chunks.
Leo Izen (2):
avcodec/pngdec: support sBIT chunks
avcodec/pngenc: write sBIT chunks
libavcodec/pngdec.c | 57 +
libavcodec/pngenc.c | 7 ++
2 files changed, 64 insertions(+)
Hey guys,
Any feedback on this patch?
Regards
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject
The matroska specification states the start time and duration of subtitle
entries are encoded in the block TimeStamp and BlockDuration. Furthermore,
for all subtitle formats except S_HDMV/PGS the BlockDuration must always be
defined and have an absolute value even if it is simply 0. ffmpeg assumes
On Tue, 3 Jan 2023 at 03:13, Philip Langdale wrote:
> On Tue, 3 Jan 2023 02:39:19 +0300
> Dennis Mungai wrote:
>
> > Related,
> >
> > If this were to be implemented in mpv, can libplacebo pick up this
> > feature spec as a filter in ffmpeg? Perhaps that would make such a
> > feature easier to
On Tue, 3 Jan 2023 02:39:19 +0300
Dennis Mungai wrote:
> Related,
>
> If this were to be implemented in mpv, can libplacebo pick up this
> feature spec as a filter in ffmpeg? Perhaps that would make such a
> feature easier to merge down the line, instead of re-implementing it
> directly in
On Tue, 3 Jan 2023 at 02:22, Philip Langdale wrote:
> This filter implements frame rate down/upsampling using nvidia's
> Optical Flow FRUC (Frame Rate Up Conversion) library. It's neat because
> you get realtime interpolation with a decent level of quality. It's
> impractical because of
This filter implements frame rate down/upsampling using nvidia's
Optical Flow FRUC (Frame Rate Up Conversion) library. It's neat because
you get realtime interpolation with a decent level of quality. It's
impractical because of licensing.
I have no actual intention to merge this, as it doesn't
This enables pushing TTML together with another track (usually video)
as part of CMAF Ingest, as defined by the DASH-IF Live Media Ingest
Protocol.
Currently does not function well with just the subtitle track unless
the API user explicitly requests fragmentation with a nullptr packet,
as the
On Sat, 2022-11-19 at 16:35 -0500, Rick Kern wrote:
> objpool was only being used in fftools, but it's useful in other
> components to reduce alloation time and memory fragmentation.
>
> This patch set moves objpool to libavutil, so it can be used by
> lavc/videotoolboxenc for data being passed
objpool was only being used in fftools, but it's useful in other components to
reduce alloation time and memory fragmentation.
This patch set moves objpool to libavutil, so it can be used by
lavc/videotoolboxenc for data being passed from input frames to output packets.
Rick Kern (2):
This is split out from my earlier patchset "SEI parsing for QSV decoders"
(https://github.com/ffstaging/FFmpeg/pull/31) as it is only logically
related but not technically.
The first patch had been reviewed and partially authored by Anton (I have
indicated this with a signed-off line, please
Example out put for command: ffmpeg -h filters=overlay
Filter overlay
Overlay a video source on top of the input.
slice threading supported
Inputs:
#0: main (video), Formats: Dynamic, Default: [yuv420p, yuvj420p,
yuva420p, nv12, nv21]
#1: overlay (video), Formats:
On 10/2/22 03:58, Leo Izen wrote:
FFmpeg has supported these pixel formats since 7bb0afc245d093b0 and
libjxl supports receiving/sending these pixel formats so it makes
sense to add support to the libjxl wrapper for these formats.
Bumping for review.
- Leo Izen
FFmpeg has supported these pixel formats since 7bb0afc245d093b0 and
libjxl supports receiving/sending these pixel formats so it makes
sense to add support to the libjxl wrapper for these formats.
Leo Izen (2):
avutil/pixfmt.h: add native-endian RGB32F and RGBA32F formats
avcodec/libjxl: use
Recently libFLAC gained the ability (not in any released version yet
though) to create FLAC files containing 32-bit int PCM samples. To
keep complexity reasonable, the choice was made to limit residuals
to 32-bit integers, which the encoder must make sure of. In case
the encoder cannot find any
Provide neon implementations for motion estimation functions.
Hubert Mazur (2):
lavc/aarch64: Assign callback with function
lavc/aarch64: Add pix_abs16_x2 neon implementation
libavcodec/aarch64/me_cmp_init_aarch64.c | 5 +
libavcodec/aarch64/me_cmp_neon.S | 134
On Mon, 13 Jun 2022, Swinney, Jonathan wrote:
Here is an updated patch series for the yuv2plane[X|1] implementations
and tests. The checkasm test wasn't working at all for aarch64, and the
x86_64 behavior differs from the default implementation so I had to
include some code to specialize the
The NLQ pivots are not documented but should be present
in the header for profile 7 RPU format.
It has been verified using Dolby's verification toolkit.
With the pivots parsed, the parsed values for
num_{x,y}_partitions are correct and usually equal to 1.
quietvoid (2):
libavutil/dovi_meta:
This introduces ff_draw_init2, adding support for colorspaces other than
BT601 and explicit full/limited range configuration.
rcombs (2):
lavfi/colorspace: add ff_matrix_mul_3x3_vec
lavfi/drawutils: improve colorspace support
libavfilter/colorspace.c | 11 +
> -Original Message-
> From: ffmpeg-devel On Behalf Of nil-
> admir...@mailo.com
> Sent: Monday, May 16, 2022 10:45 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 0/2] Support long file names on
> Windows
>
> > I have left
> I have left those out by intention because they are pending removal
> and are only for debugging.
Is dvdsubdec.c parse_ifo_palette pending removal? What about
- vf_pnsr.c init()
- vf_vidstabdetect.c config_input()
- vf_vidstabtransform.c config_input()?
> -Original Message-
> From: ffmpeg-devel On Behalf Of nil-
> admir...@mailo.com
> Sent: Sunday, May 15, 2022 9:36 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 0/2] Support long file names on
> Windows
>
> > I have kept the
> I have kept the individual functions separate on purpose, to make it easy to
> compare with the .NET impl. (compilers should inlinie those anyway)
Calling add_extended_prefix without pre-validation results in error,
since it does check for \\?\, \\.\, or \??\; only it's wrapper
> -Original Message-
> From: ffmpegagent
> Sent: Friday, May 13, 2022 11:53 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz
> Subject: [PATCH 0/2] Support long file names on Windows
>
> This patchset adds support for long file and directory paths on
> Windows. The
> implementation
This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same function is also used for other purposes,
Unify file access operations by replacing usages of direct calls to posix
fopen()
softworkz (2):
fftools: use av_fopen_utf8() instead of plain fopen()
avfilter: use av_fopen_utf8() instead of plain fopen()
fftools/cmdutils.c| 6 +++---
fftools/ffmpeg.c | 4 ++--
Add proper colorspace handling and tagging to the libjxl
decoder and encoder wrappers.
Leo Izen (2):
avcodec/libjxldec: properly tag output colorspace
avcodec/libjxlenc: properly read input colorspace
libavcodec/libjxl.h| 9 +++
libavcodec/libjxldec.c | 121
On Sat, Apr 23, 2022 at 10:39 PM Leo Izen wrote:
>
> I missed the version.h bump when rebasing the Jpeg XL
> patchset onto master. This should properly bump the minor
> library versions.
>
> Leo Izen (2):
> avcodec/version.h: bump version for Jpeg XL
> avformat/version.h: bump version for
I missed the version.h bump when rebasing the Jpeg XL
patchset onto master. This should properly bump the minor
library versions.
Leo Izen (2):
avcodec/version.h: bump version for Jpeg XL
avformat/version.h: bump version for Jpeg XL
libavcodec/version.h | 2 +-
libavformat/version.h | 2 +-
Andreas Schneider:
> Just some small header cleanup.
>
> Andreas Schneider (2):
> avcodec/exif: Include bytestream.h for GetByteContext
> avcodec/exif: Include tiff_common.h only where needed
>
> libavcodec/exif.c | 1 +
> libavcodec/exif.h | 2 +-
> libavcodec/mjpegdec.c | 1 +
>
Just some small header cleanup.
Andreas Schneider (2):
avcodec/exif: Include bytestream.h for GetByteContext
avcodec/exif: Include tiff_common.h only where needed
libavcodec/exif.c | 1 +
libavcodec/exif.h | 2 +-
libavcodec/mjpegdec.c | 1 +
libavcodec/webp.c | 1 +
4 files
On 2021-12-31 19:33, Andreas Rheinhardt wrote:
> John-Paul Stewart:
>> On 2021-12-31 17:19, Andreas Rheinhardt wrote:
>>> John-Paul Stewart:
Recent discussion on the list led me to realize that libavformat was
unconditionally creating an audio stream for all SGI movie format
John-Paul Stewart:
> On 2021-12-31 17:19, Andreas Rheinhardt wrote:
>> John-Paul Stewart:
>>> Recent discussion on the list led me to realize that libavformat was
>>> unconditionally creating an audio stream for all SGI movie format
>>> (version 2) files, even when no audio is present in the file.
On 2021-12-31 17:19, Andreas Rheinhardt wrote:
> John-Paul Stewart:
>> Recent discussion on the list led me to realize that libavformat was
>> unconditionally creating an audio stream for all SGI movie format
>> (version 2) files, even when no audio is present in the file.
>>
>> A sample of a
John-Paul Stewart:
> Recent discussion on the list led me to realize that libavformat was
> unconditionally creating an audio stream for all SGI movie format
> (version 2) files, even when no audio is present in the file.
>
> A sample of a movie file with no audio can be found at
>
Recent discussion on the list led me to realize that libavformat was
unconditionally creating an audio stream for all SGI movie format
(version 2) files, even when no audio is present in the file.
A sample of a movie file with no audio can be found at
Hi John-Paul,
On Sat, Nov 27, 2021 at 8:22 PM John-Paul Stewart <
jpstew...@personalprojects.net> wrote:
> On 2021-11-27 8:51 a.m., Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Nov 26, 2021 at 4:52 PM John-Paul Stewart <
> > jpstew...@personalprojects.net> wrote:
> >
> >> There were no single
Hi,
On Fri, Nov 26, 2021 at 4:52 PM John-Paul Stewart <
jpstew...@personalprojects.net> wrote:
> There were no single channel examples and no 8 bit
> examples.
>
> I have created four clips with SGI's original 'moviemaker' utility (so
> they are guaranteed to be correctly formatted) to reverse
As per discussion here:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211012135040.764167-1-derek.buitenh...@gmail.com/
Derek Buitenhuis (2):
avformat/mov: Use av_rescale when calculating bit rate
avformat/mov: Do not hard fail if bit rate calculation overflows
unless in explode
To keep it simpler this first part includes only non-fragmented use
cases. Contains the basic mapping code as well as the function that
writes out the squashed documents.
Works with both subtitle-only output as well as with other streams.
Currently attempts to see the lengthiest streams in the
These two patches check if a DirectShow device provides color
information and sets this in the AVStream. If a device provides equivalent
formats with and without color information, the format with color information
is used.
I'm a first-time contributor, hope all is in order.
Example output of
This is a patch originally, submitted in 2017 (author/date info left
intact). At the time, it didn't get much attention I assume due to the
sheer size of it. I have split the patch into only its QPEL/EPEL parts,
rebasing, and doing some cleaning of the patches as much is reasonable
for a 9001 line
Derek Buitenhuis (2):
avcodec/gifenc: Add global_palette option
avcodec/gifenc: Only write frame palette entries that actually used
libavcodec/gif.c | 93 ++--
1 file changed, 82 insertions(+), 11 deletions(-)
--
2.30.0
These are two completely independant patchs.
My use case is that I have many progressive materials and only a few interlaced,
and I just want to avoid inserting a deinterlacing filter if it is not required.
Thank you for the review
Nicolas
Nicolas Gaullier (2):
avformat/mov: always parse video
36
>>>> À : FFmpeg development discussions and patches
>>>> Objet : Re: [FFmpeg-devel] [PATCH 0/2] avcodec/dolby_e: Add a parser
>>>>
>>>>
>>>>
>>>> Changes looks trivial enough.
>>>>
>>>
>>> If no on
On 1/25/2021 12:35 PM, Lynne wrote:
Jan 25, 2021, 12:03 by nicolas.gaullier@cji.paris:
De : ffmpeg-devel De la part de Paul B Mahol
Envoyé : jeudi 21 janvier 2021 13:36
À : FFmpeg development discussions and patches
Objet : Re: [FFmpeg-devel] [PATCH 0/2] avcodec/dolby_e: Add a parser
Jan 25, 2021, 12:03 by nicolas.gaullier@cji.paris:
> >De : ffmpeg-devel De la part de Paul B
> >Mahol
> >Envoyé : jeudi 21 janvier 2021 13:36
> >À : FFmpeg development discussions and patches
> >Objet : Re: [FFmpeg-devel] [PATCH 0/2] avcodec/dolby_e: Add a p
On Mon, Jan 25, 2021 at 12:04 PM Nicolas Gaullier
wrote:
> >De : ffmpeg-devel De la part de Paul B
> Mahol
> >Envoyé : jeudi 21 janvier 2021 13:36
> >À : FFmpeg development discussions and patches
> >Objet : Re: [FFmpeg-devel] [PATCH 0/2] avcodec/dolby_e: Add a
>De : ffmpeg-devel De la part de Paul B Mahol
>Envoyé : jeudi 21 janvier 2021 13:36
>À : FFmpeg development discussions and patches
>Objet : Re: [FFmpeg-devel] [PATCH 0/2] avcodec/dolby_e: Add a parser
>
>Changes looks trivial enough.
If no one object, the two patches may be a
Changes looks trivial enough.
On Thu, Jan 21, 2021 at 1:30 PM Nicolas Gaullier
wrote:
> >De : Nicolas Gaullier
> >Envoyé : jeudi 14 janvier 2021 17:26
> >À : ffmpeg-devel@ffmpeg.org
> >Cc : Nicolas Gaullier
> >Objet : [PATCH 0/2] avcodec/dolby_e: Add a parser
> >
> >I have limited duplicated
>De : Nicolas Gaullier
>Envoyé : jeudi 14 janvier 2021 17:26
>À : ffmpeg-devel@ffmpeg.org
>Cc : Nicolas Gaullier
>Objet : [PATCH 0/2] avcodec/dolby_e: Add a parser
>
>I have limited duplicated code by making the decoder calling the parser.
>An option would be to leave all common code to
I have limited duplicated code by making the decoder calling the parser.
An option would be to leave all common code to dolby_e.c and move decoding to
dolby_edec.c,
but that would require either to duplicate 3 "very-internal" functions
(skip_input/parse_key/convert_input) 3x times instead of
From: Mark Reid
Hi,
I'm not sure how I didn't notice this before but the f32 to yuv conversion
is slightly off. the folowinng 2 patches fix it.
In doing this I found that one of the exr tests probably wasn't testing the
right
layer, so I fixed that before.
Mark Reid (2):
fate: use correct
On 8/18/2020 4:53 PM, James Almer wrote:
> More details within each patch.
>
> James Almer (2):
> avcodec/packet: move AVPacketList definition and function helpers over
> from libavformat
> avcodec/decode: use a packet list to store copies of packets fed to
> the decoder
>
>
More details within each patch.
James Almer (2):
avcodec/packet: move AVPacketList definition and function helpers over
from libavformat
avcodec/decode: use a packet list to store copies of packets fed to
the decoder
libavcodec/avpacket.c| 64 ++
On 07-07-2020 04:42 pm, vectronic wrote:
On 11 May 2020, at 16:46, Gyan Doshi wrote:
On 11-05-2020 06:44 pm, vectronic wrote:
On 5 May 2020, at 06:19, Gyan Doshi wrote:
On 05-05-2020 03:16 am, vectronic wrote:
On 4 May 2020, at 17:56, Gyan Doshi wrote:
On 04-05-2020 09:54 pm,
1 - 100 of 320 matches
Mail list logo
