The codec ID addition needs entry in doc/APIchanges.
I believe I have a capture card with this chip and will be
able to test it in the coming 3-7 days.
Otherwise LGTM.
This could be really useful for capturing from analog sources.
Thank you,
___
ffmpeg-
This makes sense to me now.
I think it makes more sense to follow the A53
approach and be consistent.
May I suggest the following in the patch to also
improve readability in this crowded area of code:
- SCTE-20 section: as you are declaring `cap` to be
`s1->a53_buf_ref->data + old_size` now, the
The packet starts 'IVT0' or 'ivt0'; for more details see
https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/decoders/avformatdecoder.cpp
'I' = 0x49, 'i' = 0x69
---
libavformat/mpeg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
inde
---
libavcodec/codec_desc.c | 6 ++
libavcodec/codec_id.h | 1 +
libavcodec/version.c| 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index bc9163bf98..38aed994d9 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/
On 12/12/24 16:50, James Almer wrote:
On 12/12/2024 3:47 AM, Anton Khirnov wrote:
Quoting James Almer (2024-11-30 14:41:20)
with no speaker location implied
Also, is it really the case that no speaker location is implied? I'd
think mono (as opposed to just "1 channel") does carry the implicat
On 12/13/24 17:39, Marth64 wrote:
Hi Scott,
Thanks for sharing this. I had read your original email also
([RFC] libavcodec/mpeg12dec.c: CC data from skipped frames)
and was thinking about the statement. The patch helps
visualize the issue a bit better.
I need to study this and test it to unders
On Tue, Dec 10, 2024 at 10:37 PM flow gg wrote:
> Thank you, this approach can indeed address similar if else scenarios.
>
> vsetvlstatic \w, \vlen, e8, mf8, mf4, mf2, m1, m2, m4
> vsetvlstatic \w, \vlen, e16, mf4, mf2, m1, m2, m4, m8
> vsetvlstatic \w, \vlen, e32, mf2, m1, m2, m4, m8, m8
>
> I p
Hi Scott,
Thanks for sharing this. I had read your original email also
([RFC] libavcodec/mpeg12dec.c: CC data from skipped frames)
and was thinking about the statement. The patch helps
visualize the issue a bit better.
I need to study this and test it to understand it better.
Meantime, I will app
Hi Kieran
On Fri, Dec 13, 2024 at 09:24:17AM +, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, 13 Dec 2024, 02:46 Michael Niedermayer,
> wrote:
>
> > Hi
> >
> > On Fri, Dec 13, 2024 at 01:40:43AM +, Kieran Kunhya via ffmpeg-devel
> > wrote:
> > > On Thu, 12 Dec 2024, 13:07 Nicolas Gaull
Will push in a few hours.
___
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 "unsubscribe".
Will push in a few hours.
___
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 "unsubscribe".
Hi Michael,
On Fri, Dec 13, 2024, 16:48 Michael Niedermayer
wrote:
> Hi all
>
> Iam not sure why the CC vote is being delayed. But given that it is
> apparently,
>
> id like to repeat my call for more independant candidates to volunteer
> for the CC.
>
> IMHO the community committee should be ma
Hi all
Iam not sure why the CC vote is being delayed. But given that it is
apparently,
id like to repeat my call for more independant candidates to volunteer
for the CC.
IMHO the community committee should be made of people who have NOT
fuelled fights. Who are not easily offended themselfs.
And
In mpeg_decode_a53_cc() only the A/53 part 4 CC data ("GA94") is saved between
frames. The other formats incorrectly created a larger buffer than they use
since a705bcd763e344fac191e157ffeddc285388b7fa because they did not append to
the previous data.
A/53 and SCTE-20 specify a maximum of one CC
Le 13 décembre 2024 12:14:43 GMT+02:00, Nicolas George a
écrit :
>Kieran Kunhya via ffmpeg-devel (12024-12-13):
>> Then the conclusion in your example is wrong.
>
>No it is not. Either you misunderstood what I explained
Rather what you wrote ("wave") is not what you meant, presumably "PCM". As
I intend to push this series soon.
It's been tested to work, and no major changes to the spec have happened.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or emai
---
libavformat/hevc.c | 150 -
1 file changed, 135 insertions(+), 15 deletions(-)
diff --git a/libavformat/hevc.c b/libavformat/hevc.c
index 5cde2abf8f..fc1fa8be74 100644
--- a/libavformat/hevc.c
+++ b/libavformat/hevc.c
@@ -82,6 +82,8 @@ typedef stru
Le sunnuntaina 8. joulukuuta 2024, 18.46.18 EET Anton Khirnov a écrit :
> Hi all,
> we currently have 5 candidates for CC:
> - Vittorio Giovara
> - James Almer
> - Marth64
> - Anton Khirnov
> - compn
>
> A the number of candidates equals the number of CC members, there is no
> point in holding a v
On Fri, 13 Dec 2024, 16:38 Romain Beauxis, wrote:
> Le ven. 13 déc. 2024 à 16:42, Romain Beauxis
> a écrit :
> >
> > This patch adds parameters to pick specific ports for the two FEC error-
> > correction streams associated with a Pro-MPEG CoP #3-R2 FEC streams.
> >
> > Radio France is currently
Le ven. 13 déc. 2024 à 16:42, Romain Beauxis
a écrit :
>
> This patch adds parameters to pick specific ports for the two FEC error-
> correction streams associated with a Pro-MPEG CoP #3-R2 FEC streams.
>
> Radio France is currently interested in using this technology to do
> error-correction on s
This patch adds parameters to pick specific ports for the two FEC error-
correction streams associated with a Pro-MPEG CoP #3-R2 FEC streams.
Radio France is currently interested in using this technology to do
error-correction on some of their stream. In this context, they may not
have full contro
From: Dennis Sädtler
Added in macOS 15 "Sequoia".
Signed-off-by: Dennis Sädtler
---
libavcodec/videotoolboxenc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index da7b291b03..fb2de7b960 100644
--- a/libavcodec/v
Fix test failure on aarch64:
./tests/checkasm/checkasm --test=h264pred 367840
Signed-off-by: Peng Bin
---
libavcodec/aarch64/h264pred_neon.S | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavcodec/aarch64/h264pred_neon.S
b/libavcodec/aarch64/h264pred_ne
Sent with Proton Mail secure email.
On Thursday, December 12th, 2024 at 4:18 AM, Chris Hodges
wrote:
> Hi Tristan,
>
> I have a draft reply ongoing the last couple of days, but I got
> sidetracked with other work, sorry. Will send it out without a new patch
> so we can discuss the changes
On Fri, 13 Dec 2024, 13:41 Niklas Haas, wrote:
> On Fri, 13 Dec 2024 01:37:34 + Kieran Kunhya via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> > On Fri, 13 Dec 2024, 00:39 Michael Niedermayer,
> > wrote:
> >
> > > Hi
> > >
> > > On Thu, Dec 12, 2024 at 12:54:29PM +, Nicolas Gaullie
Hi Tristan,
wow, that was a timing coincidence, I just started to write the mail
with the new patch...
On 12/13/24 14:44, Tristan Matthews via ffmpeg-devel wrote:
Do the other implementations you mentioned have that kind of information
by parsing OBUs or from the AV1 encoder?
In both they
On Thursday, December 12th, 2024 at 4:18 AM, Chris Hodges
wrote:
> Hi Tristan,
>
> thanks for taking the time reviewing.
>
> On 12/6/24 18:39, Tristan Matthews via ffmpeg-devel wrote:
>
> > Hi (also apologies if my client mangles the inline version of the patch,
> > it's the first time I've
On Fri, 13 Dec 2024 01:37:34 + Kieran Kunhya via ffmpeg-devel
wrote:
> On Fri, 13 Dec 2024, 00:39 Michael Niedermayer,
> wrote:
>
> > Hi
> >
> > On Thu, Dec 12, 2024 at 12:54:29PM +, Nicolas Gaullier wrote:
> > [...]
> > > This is a significant work with some weird things like dealing wi
On 12/10/2024 11:02 AM, James Almer wrote:
Signed-off-by: James Almer
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
tests/ref/fate/channel_layout | 1 +
4 files changed, 6 insertions(+)
Will add missing APIchanges ent
ons 2024-12-11 klockan 15:41 +0100 skrev Tomas Härdin:
> ons 2024-12-11 klockan 15:24 +0100 skrev Tomas Härdin:
> > Hi
> >
> > This patchset addresses the issues Spotify has been having reading
> > fragmented MP4 over HTTP. The issue is that mov.c does hundreds of
> > seeks unless -use_mfra_for is
On Fri, 13 Dec 2024, 10:14 Nicolas George, wrote:
> Kieran Kunhya via ffmpeg-devel (12024-12-13):
> > Then the conclusion in your example is wrong.
>
> No it is not. Either you misunderstood what I explained — I am guessing
> you only read it superficially, you did not actually try to do it for
>
Kieran Kunhya via ffmpeg-devel (12024-12-13):
> Then the conclusion in your example is wrong.
No it is not. Either you misunderstood what I explained — I am guessing
you only read it superficially, you did not actually try to do it for
yourself — or you really do not know how to use ffmpeg.
End o
On Fri, 13 Dec 2024, 10:00 Nicolas George, wrote:
> Kieran Kunhya via ffmpeg-devel (12024-12-13):
> > Where is the second sample rate stored in wav?
>
> Nowhere, obviously. I am surprised somebody who has been in the project
> for more than 12 years still does not know how it works.
>
Then the c
Kieran Kunhya via ffmpeg-devel (12024-12-13):
> Where is the second sample rate stored in wav?
Nowhere, obviously. I am surprised somebody who has been in the project
for more than 12 years still does not know how it works.
--
Nicolas George
___
ffmp
On Fri, 13 Dec 2024, 09:31 Nicolas George, wrote:
> Kieran Kunhya via ffmpeg-devel (12024-12-13):
> > Does FFmpeg even support a new sample rate per AVFrame?
>
> Generate a 48000 Hz MP3.
> Generate a 32000 Hz MP3.
> Concatenate them.
> Convert the result to wave.
> Listen to it to check it is val
Kieran Kunhya via ffmpeg-devel (12024-12-13):
> Does FFmpeg even support a new sample rate per AVFrame?
Generate a 48000 Hz MP3.
Generate a 32000 Hz MP3.
Concatenate them.
Convert the result to wave.
Listen to it to check it is valid.
Use ffprobe -show_frames to check no resampling is happening.
On Fri, 13 Dec 2024, 02:46 Michael Niedermayer,
wrote:
> Hi
>
> On Fri, Dec 13, 2024 at 01:40:43AM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Thu, 12 Dec 2024, 13:07 Nicolas Gaullier, >
> > wrote:
> >
> > > >De : ffmpeg-devel de la part de
> Anton
> > > Khirnov
> > > >Envoyé : jeudi
37 matches
Mail list logo
