Le jeu. 23 janv. 2025 à 12:31, Kieran Kunhya
a écrit :
>
> > The FEC decoder works on the demuxer/transport layer and is
> > independent from the content layer.
> >
> > The FEC decoder parameters can be set by the user according to their
> > content settings to determine the delay incurred by buff
> The FEC decoder works on the demuxer/transport layer and is
> independent from the content layer.
>
> The FEC decoder parameters can be set by the user according to their
> content settings to determine the delay incurred by buffering and
> packet loss for a CBR content.
A buffer of N packets do
Le mer. 22 janv. 2025 à 11:03, Kieran Kunhya
a écrit :
>
> On Thu, Jan 16, 2025 at 8:15 PM Romain Beauxis
> wrote:
> >
> > This patch implements the decoding logic for the FEC error-
> > correction method described in the Pro-MPEG CoP #3-R2 FEC[1]
> >
> > We are still in the process of testing t
James Almer (12025-01-20):
> Partial support for MV-HEVC, partial support for IAMF (no rendering, only
> demuxing/muxing), partial support for tiled HEIF (no stitching), the new VVC
> decoder that's afaik not 100% complete, a PTS reorder bsf that's missing
> some edge cases and support for HEVC and
> Can you please stop this "my way or no way"
The irony is not lost on me of this sentence (from the person banning
people, censoring people, creating paranoid theories about the GA).
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
On Thu, Jan 16, 2025 at 8:15 PM Romain Beauxis wrote:
>
> This patch implements the decoding logic for the FEC error-
> correction method described in the Pro-MPEG CoP #3-R2 FEC[1]
>
> We are still in the process of testing this patch with our encoders but
> I wanted to send it now in case it coul
On Wed, Jan 22, 2025 at 4:37 PM Michael Niedermayer
wrote:
>
> Hi
>
> On Mon, Jan 20, 2025 at 03:00:17PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
>
> > Error recovery protocols are complicated -
>
> everything is complicated
>
>
> > this project lacks
> > experience in them
>
> The
On Wed, Jan 22, 2025 at 4:53 PM Romain Beauxis wrote:
>
> Le mer. 22 janv. 2025 à 10:29, Kieran Kunhya via ffmpeg-devel
> a écrit :
> >
> > On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
> > wrote:
> > >
> > > On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel
> > > w
On Wed, Jan 22, 2025 at 4:37 PM Michael Niedermayer
wrote:
>
> Hi
>
> On Mon, Jan 20, 2025 at 03:00:17PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
>
> > Error recovery protocols are complicated -
>
> everything is complicated
>
>
> > this project lacks
> > experience in them
>
> The
Le mer. 22 janv. 2025 à 10:29, Kieran Kunhya via ffmpeg-devel
a écrit :
>
> On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
> wrote:
> >
> > On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel
> > wrote:
> > > >
> > > > > The data arrives on multiple sockets, leading to
Hi
On Mon, Jan 20, 2025 at 03:00:17PM +, Kieran Kunhya via ffmpeg-devel wrote:
[...]
> Error recovery protocols are complicated -
everything is complicated
> this project lacks
> experience in them
The project is made of many developers, and several of them do have
experience in protocols
On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
wrote:
>
> On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > >
> > > > The data arrives on multiple sockets, leading to all sorts
> > > > of opportunities for timing behavior and reordering issues.
> > >
> > >
On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel wrote:
> >
> > > The data arrives on multiple sockets, leading to all sorts
> > > of opportunities for timing behavior and reordering issues.
> >
> > how does this matter?
> >
>
> There are routers that put traffic on a diffe
Hi all,
Le lun. 20 janv. 2025 à 10:23, Marth64 a écrit :
>
> James Almer:
>
> > I'd really like if we can stop with the "Everything's fucked, nothing
> > can be done" mails every other week and instead make use of the
> > framework we came up with, or if needed, change it and improve it.
>
> +1
>
James Almer:
> I'd really like if we can stop with the "Everything's fucked, nothing
> can be done" mails every other week and instead make use of the
> framework we came up with, or if needed, change it and improve it.
+1
or we will never move forward with anything
__
On 1/20/2025 11:30 AM, Nicolas George wrote:
James Almer (12025-01-17):
I don't see how the GA has anything to do with this when we're talking about
one person, but you're not wrong in that rejecting a feature for being
incomplete is not ideal.
The codebase is not lacking in partially implemente
On Mon, Jan 20, 2025 at 2:51 PM Nicolas George wrote:
>
> Kieran Kunhya via ffmpeg-devel (12025-01-17):
> > I am the author of the only known functional OSS implementation of FEC.
>
> Seen from here, your rejection of this proposal looks a teeny tiny
> little bit like trying to make sure you stay
Kieran Kunhya via ffmpeg-devel (12025-01-17):
> I am the author of the only known functional OSS implementation of FEC.
Seen from here, your rejection of this proposal looks a teeny tiny
little bit like trying to make sure you stay the only one and have no
competition in providing consulting about
Devin Heitmueller (12025-01-17):
> It's an intrinsically difficult
> problem. The data arrives on multiple sockets, leading to all sorts
> of opportunities for timing behavior and reordering issues.
I will add something on top of that: The architecture of net
James Almer (12025-01-17):
> I don't see how the GA has anything to do with this when we're talking about
> one person, but you're not wrong in that rejecting a feature for being
> incomplete is not ideal.
> The codebase is not lacking in partially implemented features and protocols,
> and as long
>
> > The data arrives on multiple sockets, leading to all sorts
> > of opportunities for timing behavior and reordering issues.
>
> how does this matter?
>
There are routers that put traffic on a different port down a different ISP
so you have to compensate for latency delays between the two link
On Sun, 19 Jan 2025, 22:22 Michael Niedermayer,
wrote:
> The part i do not agree with and iam not convinced about is that this
> cannot be done in a clean and fully working and heuristics free
> way in the real world.
>
Protocols are not the same as codecs. Just because you have a hammer,
everyt
Hi Devin
On Fri, Jan 17, 2025 at 12:54:10PM -0500, Devin Heitmueller wrote:
> Hello all,
>
> I've got some experience in this particular area, so figured it might
> be helpful to offer another voice.
>
> Kieran makes a number of excellent points, and I largely agree with
> his discussion of the
On Fri, 17 Jan 2025, 21:32 Romain Beauxis, wrote:
> Le ven. 17 janv. 2025 à 08:32, Kieran Kunhya
> a écrit :
> >
> > On Fri, Jan 17, 2025 at 2:24 PM Kieran Kunhya
> wrote:
> > >
> > > On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis <
> romain.beau...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
Le ven. 17 janv. 2025 à 08:32, Kieran Kunhya
a écrit :
>
> On Fri, Jan 17, 2025 at 2:24 PM Kieran Kunhya
> wrote:
> >
> > On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis
> > wrote:
> > >
> > > Hi,
> > >
> > > Le jeu. 16 janv. 2025 à 16:40, Kieran Kunhya
> > > a écrit :
> > > >
> > > > On Thu,
> > FEC requires tons of heuristics to work in the real world.
>
> Besides your word, is there some evidence ?
>
> (and the question is not that YOUR implementation needs
> "tons of heuristics to work in the real world." or the reference
> does but that EVERY implementation does)
>
> You seem to
Hello all,
I've got some experience in this particular area, so figured it might
be helpful to offer another voice.
Kieran makes a number of excellent points, and I largely agree with
his discussion of the problem space. It's an intrinsically difficult
problem. The data arrives on multiple sock
Hi Kieran
On Fri, Jan 17, 2025 at 04:05:09PM +, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, Jan 17, 2025 at 2:48 PM James Almer wrote:
> >
> > On 1/17/2025 11:42 AM, Nicolas George wrote:
> > > James Almer (12025-01-17):
> > >> Don't assume he will not extend the implementation. Ask him i
Hi Kieran
On Fri, Jan 17, 2025 at 02:44:03PM +, Kieran Kunhya via ffmpeg-devel wrote:
> > Don't assume he will not extend the implementation. Ask him instead what
> > he plans to do in the long term.
> > And this could also be marked as experimental, in which case if
> > abandoned or proven un
> A simple and clean mpeg FEC implementation will do no harm to FFmpeg,
> instead it will improve FFmpegs capabilities.
For the reasons I have described this is not possible. It's similar to
the way the kernel hides all the idiosyncrasies of real world TCP.
Kieran
Hi Kieran
On Fri, Jan 17, 2025 at 02:32:05PM +, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, Jan 17, 2025 at 2:24 PM Kieran Kunhya
> wrote:
> >
> > On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis
> > wrote:
[...]
> For an ancient protocol like FEC, nobody is going to work on it and so
>
On Fri, Jan 17, 2025 at 2:48 PM James Almer wrote:
>
> On 1/17/2025 11:42 AM, Nicolas George wrote:
> > James Almer (12025-01-17):
> >> Don't assume he will not extend the implementation. Ask him instead what he
> >> plans to do in the long term.
> >> And this could also be marked as experimental,
On 1/17/2025 11:42 AM, Nicolas George wrote:
James Almer (12025-01-17):
Don't assume he will not extend the implementation. Ask him instead what he
plans to do in the long term.
And this could also be marked as experimental, in which case if abandoned or
proven unstable for several real world ca
> Don't assume he will not extend the implementation. Ask him instead what
> he plans to do in the long term.
> And this could also be marked as experimental, in which case if
> abandoned or proven unstable for several real world cases, it can be
> removed or disabled.
"the most simple and elegant
James Almer (12025-01-17):
> Don't assume he will not extend the implementation. Ask him instead what he
> plans to do in the long term.
> And this could also be marked as experimental, in which case if abandoned or
> proven unstable for several real world cases, it can be removed or disabled.
You
On Fri, Jan 17, 2025 at 2:24 PM Kieran Kunhya wrote:
>
> On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis
> wrote:
> >
> > Hi,
> >
> > Le jeu. 16 janv. 2025 à 16:40, Kieran Kunhya
> > a écrit :
> > >
> > > On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis
> > > wrote:
> > > >
> > > > Le jeu. 16 ja
On 1/17/2025 11:24 AM, Kieran Kunhya via ffmpeg-devel wrote:
On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis wrote:
Hi,
Le jeu. 16 janv. 2025 à 16:40, Kieran Kunhya
a écrit :
On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis wrote:
Le jeu. 16 janv. 2025 à 14:48, Kieran Kunhya
a écrit :
O
On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis wrote:
>
> Hi,
>
> Le jeu. 16 janv. 2025 à 16:40, Kieran Kunhya
> a écrit :
> >
> > On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis
> > wrote:
> > >
> > > Le jeu. 16 janv. 2025 à 14:48, Kieran Kunhya
> > > a écrit :
> > > >
> > > > On Thu, 16 Jan 2
Le ven. 17 janv. 2025 à 00:40, Christophe Gisquet
a écrit :
>
> Hello,
>
> Le jeu. 16 janv. 2025 à 21:15, Romain Beauxis
> a écrit :
> > --- a/libavformat/prompeg.c
> > +++ b/libavformat/prompeg.c
> > @@ -25,78 +25,16 @@
> > * @author Vlad Tarca
> > */
>
> [...]
>
> > --- /dev/null
> > +++ b
Hi,
Le jeu. 16 janv. 2025 à 16:40, Kieran Kunhya
a écrit :
>
> On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis
> wrote:
> >
> > Le jeu. 16 janv. 2025 à 14:48, Kieran Kunhya
> > a écrit :
> > >
> > > On Thu, 16 Jan 2025, 20:15 Romain Beauxis,
> > > wrote:
> > >>
> > >> This patch implements th
Hello,
Le jeu. 16 janv. 2025 à 21:15, Romain Beauxis
a écrit :
> --- a/libavformat/prompeg.c
> +++ b/libavformat/prompeg.c
> @@ -25,78 +25,16 @@
> * @author Vlad Tarca
> */
[...]
> --- /dev/null
> +++ b/libavformat/prompeg_utils.c
> @@ -0,0 +1,226 @@
> +/*
> + * Pro-MPEG Code of Practice #
On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis wrote:
>
> Le jeu. 16 janv. 2025 à 14:48, Kieran Kunhya
> a écrit :
> >
> > On Thu, 16 Jan 2025, 20:15 Romain Beauxis, wrote:
> >>
> >> This patch implements the decoding logic for the FEC error-
> >> correction method described in the Pro-MPEG CoP
Le jeu. 16 janv. 2025 à 14:48, Kieran Kunhya
a écrit :
>
> On Thu, 16 Jan 2025, 20:15 Romain Beauxis, wrote:
>>
>> This patch implements the decoding logic for the FEC error-
>> correction method described in the Pro-MPEG CoP #3-R2 FEC[1]
>>
>> We are still in the process of testing this patch wi
On Thu, 16 Jan 2025, 20:48 Kieran Kunhya, wrote:
> On Thu, 16 Jan 2025, 20:15 Romain Beauxis,
> wrote:
>
>> This patch implements the decoding logic for the FEC error-
>> correction method described in the Pro-MPEG CoP #3-R2 FEC[1]
>>
>> We are still in the process of testing this patch with our
On Thu, 16 Jan 2025, 20:15 Romain Beauxis, wrote:
> This patch implements the decoding logic for the FEC error-
> correction method described in the Pro-MPEG CoP #3-R2 FEC[1]
>
> We are still in the process of testing this patch with our encoders but
> I wanted to send it now in case it could use
This patch implements the decoding logic for the FEC error-
correction method described in the Pro-MPEG CoP #3-R2 FEC[1]
We are still in the process of testing this patch with our encoders but
I wanted to send it now in case it could use some early review.
The code seems clean enough and straight
46 matches
Mail list logo
