Anton Khirnov (12023-04-24):
> No actual explanation then. So I suppose what you mean is that different
> rules apply to you and everyone else.
No. I have said what I mean, I will not let you distort it to suit your
needs.
> I will, the overhead code required is trivial compared to the code
Marton Balint (12023-04-24):
> The API change is that muxers are no longer allowed to return AVERROR_EOF
> for an error condition.
There is no API change because applications are not allowed to write
muxers. At worst, it would be an internal API change.
But it is not even an internal API change,
Quoting Marton Balint (2023-04-24 21:42:26)
>
>
> On Mon, 24 Apr 2023, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2023-04-24 20:41:55)
> >>
> >>
> >> On Mon, 24 Apr 2023, Anton Khirnov wrote:
> >>
> >>> Quoting Marton Balint (2023-04-24 11:09:44)
> The real risk is that they
On 4/24/23 11:57, Michael Niedermayer wrote:
On Sun, Apr 23, 2023 at 06:21:06PM -0400, Leo Izen wrote:
From: Carl Eugen Hoyos
Support pixel formats 0x11412100, 0x11311100, and 0x41211100, and add
logic to perform 4x horizontal upsampling. This should fix various JPEG
files found in Ticket
Hi all
thilo pointed me to some spam on trac today, investigating i found a spammer
with 4 accounts who spammed ~6 tickets
thanks to the last update the permission for the admin page to delete users
seems to got a new name which slightly slowed me down.
I think i deleted all that spam.
If you
On Mon, 24 Apr 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-04-24 20:41:55)
On Mon, 24 Apr 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-04-24 11:09:44)
The real risk is that they unintentionally do that, when the error code is
coming from some underlying operation
Quoting Nicolas George (2023-04-24 21:24:20)
> Anton Khirnov (12023-04-24):
> > I have no idea what you mean by this.
>
> Try a little harder.
No actual explanation then. So I suppose what you mean is that different
rules apply to you and everyone else.
> > The only fact here is that the
Anton Khirnov (12023-04-24):
> I have no idea what you mean by this.
Try a little harder.
> You keep using these words. I don't think they mean what you think they
> mean.
Yeah, Princess Bride references are a real boost to weak arguments.
> The only fact here is that the quoted
Quoting Marton Balint (2023-04-24 20:41:55)
>
>
> On Mon, 24 Apr 2023, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2023-04-24 11:09:44)
> >> The real risk is that they unintentionally do that, when the error code is
> >> coming from some underlying operation for example.
> >>
> >> So
sön 2023-04-23 klockan 09:50 -0300 skrev James Almer:
> Signed-off-by: James Almer
> ---
> tests/fate/jpeg2000.mak | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Probably OK
/Tomas
___
ffmpeg-devel mailing list
Quoting Nicolas George (2023-04-24 20:31:49)
> Anton Khirnov (12023-04-24):
> > So when I wanted to make changes to libavfilter recently, you claimed
> > your familiarity with the code makes you more qualified to judge
> > readability. Now my familiarity with the code makes me LESS qualified.
> >
On Mon, 24 Apr 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-04-24 11:09:44)
The real risk is that they unintentionally do that, when the error code is
coming from some underlying operation for example.
So previsouly a muxer could return any error code to signal error
condition
On Mon, Apr 24, 2023 at 8:37 PM James Almer wrote:
> On 4/24/2023 3:33 PM, Paul B Mahol wrote:
> > On Mon, Apr 24, 2023 at 8:32 PM Nicolas George wrote:
> >
> >> Anton Khirnov (12023-04-24):
> >>> So when I wanted to make changes to libavfilter recently, you claimed
> >>> your familiarity with
On 4/24/2023 3:33 PM, Paul B Mahol wrote:
On Mon, Apr 24, 2023 at 8:32 PM Nicolas George wrote:
Anton Khirnov (12023-04-24):
So when I wanted to make changes to libavfilter recently, you claimed
your familiarity with the code makes you more qualified to judge
readability. Now my familiarity
On Mon, Apr 24, 2023 at 8:32 PM Nicolas George wrote:
> Anton Khirnov (12023-04-24):
> > So when I wanted to make changes to libavfilter recently, you claimed
> > your familiarity with the code makes you more qualified to judge
> > readability. Now my familiarity with the code makes me LESS
Anton Khirnov (12023-04-24):
> So when I wanted to make changes to libavfilter recently, you claimed
> your familiarity with the code makes you more qualified to judge
> readability. Now my familiarity with the code makes me LESS qualified.
> Curious.
There is a difference between long-term
On Sun, Apr 23, 2023 at 06:21:06PM -0400, Leo Izen wrote:
> From: Carl Eugen Hoyos
>
> Support pixel formats 0x11412100, 0x11311100, and 0x41211100, and add
> logic to perform 4x horizontal upsampling. This should fix various JPEG
> files found in Ticket #8930.
>
> Co-authored-by:
> ---
>
One that is fine enough to represent all DV audio sample rates. Audio
packet durations are now sample-accurate.
This largely undoes commit 76fbb0052df471075858c1cb82b04c8be7adba8d. To
avoid breaking the issue fixed by that commit, resync audio timestamps
against video if they get more than one
Current code will call avpriv_set_pts_info() for each video frame,
possibly setting a different timebase if the stream framerate changes.
This violates API conventions, as the timebase is supposed to stay
constant after stream creation.
Change the demuxer to set a single timebase that is fine
---
libavformat/dv.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavformat/dv.c b/libavformat/dv.c
index d30dc298805..49c4f421fa5 100644
--- a/libavformat/dv.c
+++ b/libavformat/dv.c
@@ -437,10 +437,13 @@ int avpriv_dv_produce_packet(DVDemuxContext *c,
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
Signed-off-by: James Almer
---
libavcodec/cfhd.c | 6 +++---
libavcodec/crystalhd.c | 4 ++--
libavcodec/cuviddec.c | 9 ++---
libavcodec/decode.c | 2 ++
libavcodec/dnxhddec.c | 14 +++---
libavcodec/dnxhdenc.c |
Quoting Nicolas George (2023-04-24 14:13:45)
> Anton Khirnov (12023-04-24):
> > What exactly is less readable? One variable gets its scope reduced, that
> > is a win in my book.
>
> Having to remember if a field is in structure x or structure y s a net
> loss that you do not see only because you
Apr 24, 2023, 11:27 by j...@chromium.org:
> From: Jeremy Wu
>
> In certain use cases, controlling the maximum frame size is critical. An
> example is when transmitting AAC packets over Bluetooth A2DP.
>
> While the spec allows the packets be fragmented (though UNRECOMMENDED),
> in practice most
Anton Khirnov (12023-04-24):
> What exactly is less readable? One variable gets its scope reduced, that
> is a win in my book.
Having to remember if a field is in structure x or structure y s a net
loss that you do not see only because you just wrote the code and have
everything freshly in mind.
Quoting Nicolas George (2023-04-24 13:59:43)
> Anton Khirnov (12023-04-24):
> > We'll have to disagree about this then. I belive lack of proper
> > structure is currently the biggest problem in ffmpeg CLI.
>
> I do not disagree on this. But this patch does not help, it just makes
> the code
Anton Khirnov (12023-04-24):
> We'll have to disagree about this then. I belive lack of proper
> structure is currently the biggest problem in ffmpeg CLI.
I do not disagree on this. But this patch does not help, it just makes
the code locally less readable. If it is to be useful at all, it is at
Quoting Nicolas George (2023-04-24 13:19:49)
> Anton Khirnov (12023-04-24):
> > Separating internal state from public interfaces is a fundamental notion
> > of object-oriented programming and is completely orthogonal to that
> > object being a part of a library or not.
>
> Using object-oriented
Anton Khirnov (12023-04-24):
> Separating internal state from public interfaces is a fundamental notion
> of object-oriented programming and is completely orthogonal to that
> object being a part of a library or not.
Using object-oriented programming to its fullest when it is not needed
is a
Quoting Nicolas George (2023-04-24 12:20:00)
> Anton Khirnov (12023-04-19):
> > Start by moving OutputStream.filtered_frame to it, which really belong
> > to the filtergraph rather than the output stream.
>
> What is the point of this? fftools/ffmpeg_filter: is not part of a
> library, concepts
Anton Khirnov (12023-04-19):
> Previously they would only be used with trivial filtergraphs, because
> filters did not handle frame durations. That is no longer true - most
> filters process frame durations properly (there may still be some that
> don't - this change will help finding and fixing
Anton Khirnov (12023-04-19):
> Start by moving OutputStream.filtered_frame to it, which really belong
> to the filtergraph rather than the output stream.
What is the point of this? fftools/ffmpeg_filter: is not part of a
library, concepts of public/private do not apply, just put everything
you
Quoting Marton Balint (2023-04-24 11:09:44)
>
>
> On Sun, 23 Apr 2023, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2023-04-23 20:15:13)
> >>
> >>
> >> On Sun, 23 Apr 2023, Anton Khirnov wrote:
> >> I don't understand. A good program propagates back error conditions to the
> >> user, and
Quoting Marton Balint (2023-04-24 11:09:44)
> The real risk is that they unintentionally do that, when the error code is
> coming from some underlying operation for example.
>
> So previsouly a muxer could return any error code to signal error
> condition and reasonably assume that ffmpeg.c
From: Jeremy Wu
In certain use cases, controlling the maximum frame size is critical. An
example is when transmitting AAC packets over Bluetooth A2DP.
While the spec allows the packets be fragmented (though UNRECOMMENDED),
in practice most headsets do not recognize nor reassemble such packets.
Marton Balint (12023-04-24):
> The change in ffmpeg.c "forces" muxers to check if they ever get AVERROR_EOF
> for some real error condition and map them to e.g. AVERROR(EIO). And that is
> an API change.
Indeed. And the documentation agrees:
* @return < 0 on error, = 0 if OK, 1 if flushed and
In certain use cases, controlling the maximum frame size is critical. An
example is when transmitting AAC packets over Bluetooth A2DP.
While the spec allows the packets be fragmented (though UNRECOMMENDED),
in practice most headsets do not recognize nor reassemble such packets.
In this patch,
On Sun, 23 Apr 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-04-23 20:15:13)
On Sun, 23 Apr 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-04-23 12:05:51)
On Sun, 23 Apr 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-04-23 11:42:48)
On Sun, 23 Apr 2023,
In certain use cases, controlling the maximum frame size is critical. An
example is when transmitting AAC packets over Bluetooth A2DP.
While the spec allows the packets be fragmented (though UNRECOMMENDED),
in practice most headsets do not recognize nor reassemble such packets.
In this patch,
Apr 22, 2023, 14:38 by an...@khirnov.net:
> Quoting Lynne (2023-04-19 16:47:11)
>
>> Apr 17, 2023, 11:07 by an...@khirnov.net:
>>
>> > Quoting Anton Khirnov (2023-04-16 22:38:16)
>> >
>> >> Quoting Lynne (2023-03-14 07:33:43)
>> >> > From 61f412eea3fbcb1e2a8625796760c0e24fa3fb83 Mon Sep 17
Apr 22, 2023, 14:42 by an...@khirnov.net:
> Quoting Lynne (2023-04-19 16:39:28)
>
>> Apr 17, 2023, 11:25 by an...@khirnov.net:
>>
>> > Quoting Lynne (2023-03-14 07:33:43)
>> >
>> >> From 6e2dfc44e50798264eb16bc2dcabfdbf2fbac2d7 Mon Sep 17 00:00:00 2001
>> >> From: Lynne
>> >> Date: Thu, 15 Dec
Quoting metamuffin (2023-04-24 09:21:06)
> On 23-04-24 08:36, Anton Khirnov wrote:
>
> Thanks for your reply!
>
> > Also, your email client mangled your patch.
>
> Sorry for that, I will resend the updated patch soon. (hopefully using
> git send-mail)
>
> > This seems like it should be a
On 23-04-24 08:36, Anton Khirnov wrote:
Thanks for your reply!
> Also, your email client mangled your patch.
Sorry for that, I will resend the updated patch soon. (hopefully using
git send-mail)
> This seems like it should be a lavfi source instead.
If you mean libavfilter, then I am
Quoting metamuffin (2023-04-23 14:24:41)
> Added a minimal (and partial) input device for pipewire.
> The implementation lacks audio support for now since alsa and pulse can
> do that too
> Video output is not included yet. The patch requires _XOPEN_SOURCE=700
> to work.
>
> Signed-off-by:
44 matches
Mail list logo
