Thanks. Is there anything else that does not fit codebase tradition? Please
point everything out so I could send a new patch.
On Sun, Apr 30, 2023 at 3:06 AM Michael Niedermayer
wrote:
> On Sat, Apr 29, 2023 at 02:53:06PM +0900, SuperFashi wrote:
> > v1 -> v2: Refactor using GetByteContext; Fix
On Sat, 29 Apr 2023 at 05:07, Derek Buitenhuis
wrote:
> On 4/29/2023 10:41 AM, Anton Khirnov wrote:
> > ffprobe:
> > * is not one of the libraries, but rather their caller
> > * we are not in business of providing random non-multimedia-related
> > services to callers, unless they are useful in
On 4/12/2023 4:49 PM, James Almer wrote:
Signed-off-by: James Almer
---
Missing version bump and APIChanges entry.
libavutil/frame.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 5b58c14ac3..87e0a51226 100644
--- a/libavutil/frame.h
On 4/27/2023 12:39 PM, James Almer wrote:
This allows the usage of codecs in builds that have a parser but no decoders
for remuxing scenarios with raw sources.
Signed-off-by: James Almer
---
libavcodec/parser.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/parser.c
Anton Khirnov (12023-04-29):
> libavfilter is a C library with a C API. Any structured output from
> filters should be in the form of a C object, typically a struct. I do
> not see why are you so in love with strings, they make for terrible
> APIs.
Yes, strings are a terrible API, but our project
Quoting Nicolas George (2023-04-29 19:11:52)
> Anton Khirnov (2023-04-29):
> > As far as I can see, there are exactly two places in the codebase that
> > produce JSON: af_loudnorm and ffprobe.
>
> I think I remember finding a few other places, but it does not matter
> much.
>
> Users have been
On Sat, Apr 29, 2023 at 02:53:06PM +0900, SuperFashi wrote:
> v1 -> v2: Refactor using GetByteContext; Fix compile error.
> v2 -> v3: Remove debug statement.
> v3 -> v4: Squash commits (sorry, first time git patch user :(
>
> This patch adds an MPEG Media Transport Protocol (MMTP) parser, as
James Almer (12023-04-29):
> It should be exporting frame metadata
Not really. Exporting information to frame data is a hack, “this looks
pointy, we have a hammer, let's nail it”.
It only works if the data is very flat.
It does not work for data that comes at the end of the stream.
It still
Anton Khirnov (12023-04-29):
> As far as I can see, there are exactly two places in the codebase that
> produce JSON: af_loudnorm and ffprobe.
I think I remember finding a few other places, but it does not matter
much.
Users have been asking¹ for parse-friendly output from filters for years,
and
James Almer (12023-04-29):
> History has shown that these notifications have had no effect on users, and
> even on this same project's developers. A good example was ffserver.c, which
> accessed an unholy amount of lavf private fields (both exposed in public
> headers and even internal ones), and
On 4/29/2023 9:17 AM, Anton Khirnov wrote:
> What important problem within the scope of the project is being solved
> by this? Why do we need over a 1000 lines of just new header files for
> it? Why do we need a generic JSON writer? We are not a JSON library.
> Neither are we a string processing
On 4/29/2023 10:41 AM, Anton Khirnov wrote:
> ffprobe:
> * is not one of the libraries, but rather their caller
> * we are not in business of providing random non-multimedia-related
> services to callers, unless they are useful in our libraries;
> if this code is only useful in ffprobe then it
On 4/29/2023 6:41 AM, Anton Khirnov wrote:
Quoting Nicolas George (2023-04-29 11:11:59)
Nicolas George (12023-04-28):
Signed-off-by: Nicolas George
---
libavutil/Makefile | 1 +
libavutil/json.c | 368 +++
libavutil/json.h | 470
On 4/29/2023 6:13 AM, Nicolas George wrote:
Anton Khirnov (12023-04-29):
That does not follow at all - just because something was moved once does
not mean it cannot be moved again if a better place is found later.
Good, then you should have no objection to replacing your private
structure
Please see new version.
On Sat, Apr 29, 2023 at 20:38 Jean-Baptiste Kempf wrote:
> On Sat, 29 Apr 2023, at 07:44, SuperFashi wrote:
> > +#define AVERROR_INVALIDDATA (abort(), 0)
>
> Why are you aborting?
>
> --
> Jean-Baptiste Kempf - President
> +33 672 704 734
>
On Sat, 29 Apr 2023, at 07:44, SuperFashi wrote:
> +#define AVERROR_INVALIDDATA (abort(), 0)
Why are you aborting?
--
Jean-Baptiste Kempf - President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Quoting Nicolas George (2023-04-29 11:11:59)
> Nicolas George (12023-04-28):
> > Signed-off-by: Nicolas George
> > ---
> > libavutil/Makefile | 1 +
> > libavutil/json.c | 368 +++
> > libavutil/json.h | 470 +
> >
Anton Khirnov (12023-04-29):
> That does not follow at all - just because something was moved once does
> not mean it cannot be moved again if a better place is found later.
Good, then you should have no objection to replacing your private
structure with a “/* these fields are private to… */”
Nicolas George (12023-04-28):
> Signed-off-by: Nicolas George
> ---
> libavutil/Makefile | 1 +
> libavutil/json.c | 368 +++
> libavutil/json.h | 470 +
> 3 files changed, 839 insertions(+)
> create mode 100644
Quoting Nicolas George (2023-04-29 10:46:31)
> Nicolas George (12023-04-28):
> > And during the work of turning all into threads, opportunities to split
> > the structure in more logical ways with less code noise will almost
> > certainly present themselves.
>
> I had intended to not reply
Nicolas George (12023-04-28):
> And during the work of turning all into threads, opportunities to split
> the structure in more logical ways with less code noise will almost
> certainly present themselves.
I had intended to not reply further on this, but I just had a severe
case of esprit de
I've said this before, repeating it again for ease of reference: I do
not believe the use case for this has been sufficiently established.
What important problem within the scope of the project is being solved
by this? Why do we need over a 1000 lines of just new header files for
it? Why do we
Stop using InputStream.dts for generating missing timestamps for decoded
frames, because it contains pre-decoding timestamps and there may be
arbitrary amount of delay between input packets and output frames (e.g.
dependent on the thread count when frame threading is used). It is also
in
could you also try adding one more parameter and try again?
* -header_spacing 30*it should have the same value as -g in commandline.
For example: *ffmpeg -i input.mkv -c:v h264_amf -g 30 -header_spacing 30
output.mp4*
ср, 19 апр. 2023 г. в 07:15, 罗勇刚(Yonggang Luo) :
> thanks， I have
24 matches
Mail list logo
