On Sat, Feb 10, 2024, at 9:30 PM, j...@jonb.org wrote:
> From: Jonathan Baudanza
>
> libwebrtc will add audio level (in decibels) and VAD status to each RTP
> packet.
>
> This patch will add both values to the packet sidedata.
>
> I've been using this patch in p
Does anyone have any thoughts on this? This is a pretty small one-liner.
I also noticed that there is a ff_parse_ntp_time() in utils.c. Maybe this
functionality should be consolidated in one place.
On Wed, Sep 4, 2024, at 5:06 PM, j...@jonb.org wrote:
> From: Jonathan Baudanza
>
This patch to libavcodec/opus.c will create the opus extradata if it is
missing. This is required when muxing opus data from an RTP demuxer. Without
this patch, the opux muxer will fail with a "No extradata present" error.
This issue was first reported by Juan Navarro here:
http://www.ffmpeg-a
> Actually its not impossible to create extradata from raw Opus streams.
> The extradata only contains a magic, #channes, padding, a sample rate and
> a channel_family.
>
> We know the magic, the #channels can be found out via the packet's
> contents and whether it contains multiple packets, the p
On Tue, Dec 29, 2020, at 6:41 AM, Lynne wrote:
> Dec 28, 2020, 19:03 by j...@jonb.org:
>
> >> Actually its not impossible to create extradata from raw Opus streams.
> >> The extradata only contains a magic, #channes, padding, a sample rate and
> >> a channel_family.
> >>
> >> We know the magic, th
On Tue, Dec 29, 2020, at 3:25 PM, Jonathan Baudanza wrote:
> Thank you for all the feedback everyone. I've updated the patch to build the
> opus header inside of ff_rtp_parse_open in libavformat/rtpdec.c.
>
> I set the mapping_family to 0, since I believe Opus/RTP only suppo
On Wed, Dec 30, 2020, at 10:34 AM, James Almer wrote:
> Nothing should have done it at that point. The demuxer allocates the
> AVStream after all. But to be sure you can do
> av_freep(&st->codecpar->extradata) to ensure it's NULL before anything
> else is done.
Thanks James.
I've updated the
On Sun, Jan 3, 2021, at 12:50 PM, Andreas Rheinhardt wrote:
>
> It would be better if you used ff_alloc_extradata(): It also already
> frees the extradata that might be present. And it does only set the
> extradata_size after the allocation succeeded. But it is of course even
> better if you actua
On Sun, Jan 3, 2021, at 2:25 PM, Lynne wrote:
> > +/* Input sample rate (0 = unspecified) */> +bytestream_put_le32
> > (&bs, 0);
> Put in 48000 here. Stream copy will preserve extradata, and we don't want to
> generate weird streams, even if our decoder ignores this.
>
> > +/* Chan
On Sun, Jan 3, 2021, at 3:33 PM, James Almer wrote:
>
> Made those changes and pushed it.
Thanks for your help everyone! Looking forward to deploying this!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-
On Sun, Jan 3, 2021, at 3:34 PM, Andreas Rheinhardt wrote:
> Lynne:
> >
> > Apart from that LGTM.
>
> +1 if the case of more than two channels has been properly tested.
>
I tested this by creating an (invalid) SDP file with channels set to 3. In this
case, the rtp demuxer fails with the followi
On Tue, Nov 26, 2024, at 1:35 AM, j...@jonb.org wrote:
>
> This patch replaces av_rescale, which operates on int64_t, with
> ff_parse_ntp_time, which operates on uint65_t. This will give the correct
> values for timestamps back around the NTP epoch and present day timestamps.
>
Any feedback
On Mon, Jan 6, 2025, at 12:46 PM, Alexander Strasser via ffmpeg-devel wrote:
>
> Patch looks plausible except for the uint65_t typo and the long
> lines in the commit message.
>
> Will give it a try and push if it works and there are no objections
> from other developers.
>
Thank for for the fe
s.c
new file mode 100644
index 000000..1588f6d715
--- /dev/null
+++ b/libavformat/rtpdec_opus.c
@@ -0,0 +1,117 @@
+/*
+ * RTP Depacketization of Opus, RFC 7587
+ * Copyright (c) 2025 Jonathan Baudanza
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it
I'll resubmit this with a proper commit message.
___
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".
s.c
new file mode 100644
index 000000..1588f6d715
--- /dev/null
+++ b/libavformat/rtpdec_opus.c
@@ -0,0 +1,117 @@
+/*
+ * RTP Depacketization of Opus, RFC 7587
+ * Copyright (c) 2025 Jonathan Baudanza
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it
s.c
new file mode 100644
index 000000..1588f6d715
--- /dev/null
+++ b/libavformat/rtpdec_opus.c
@@ -0,0 +1,117 @@
+/*
+ * RTP Depacketization of Opus, RFC 7587
+ * Copyright (c) 2025 Jonathan Baudanza
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it
Does anyone have feedback on this?
Here are some steps to reproduce the current issue:
# Start broadcasting
ffmpeg -re -i input.opus -c:a copy -f rtp -sdp_file stream.sdp
rtp://127.0.0.1:9000
# Start recording (in another terminal)
ffmpeg -protocol_whitelist file,udp,rtp -i stream.sdp -y -c:a
18 matches
Mail list logo
