[FFmpeg-devel] [PATCH] Push hls_ts_options to every chunks (fix #5525)
Signed-off-by: jack
---
libavformat/hlsenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a9fa5d8..77712d0 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -624,6 +624,11 @@ static int hls_start(AVFormatContext *s)
err = avformat_write_header(vtt_oc,NULL);
if (err < 0)
return err;
+} else {
+HLSContext *hls = s->priv_data;
+av_dict_copy(&options, hls->format_options, 0);
+avformat_write_header(hls->avf, &options);
+av_dict_free(&options);
}
return 0;
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/tcp: add local_addr/local_port for network option
Signed-off-by: jack
---
libavformat/tcp.c | 44
1 file changed, 44 insertions(+)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index a11ccbb913..598d61067e 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -36,6 +36,8 @@ typedef struct TCPContext {
const AVClass *class;
int fd;
int listen;
+int local_port;
+char *local_addr;
int open_timeout;
int rw_timeout;
int listen_timeout;
@@ -52,6 +54,8 @@ typedef struct TCPContext {
#define E AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
{ "listen", "Listen for incoming connections", OFFSET(listen),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, .flags = D|E },
+{ "local_port", "Local port",
OFFSET(local_port), AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
+{ "local_addr", "Local address",
OFFSET(local_addr), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0,
.flags = D|E },
{ "timeout", "set timeout (in microseconds) of socket I/O operations",
OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
{ "listen_timeout", "Connection awaiting timeout (in milliseconds)",
OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
{ "send_buffer_size", "Socket send buffer size (in bytes)",
OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
@@ -73,6 +77,39 @@ static const AVClass tcp_class = {
static void customize_fd(void *ctx, int fd)
{
TCPContext *s = ctx;
+
+if (s->local_addr) {
+struct addrinfo hints = { 0 }, *ai;
+int ret;
+int port = 0;
+
+hints.ai_family = AF_UNSPEC;
+hints.ai_socktype = SOCK_STREAM;
+
+if (s->local_port > 0)
+port = s->local_port;
+
+ret = getaddrinfo(s->local_addr, "0", &hints, &ai);
+if (ret) {
+av_log(ctx, AV_LOG_WARNING,
+ "Failed to bind local addr: %s port: %d err: %s\n",
+s->local_addr, s->local_port, gai_strerror(ret));
+} else {
+if (ai->ai_family == AF_INET6) {
+struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6
*)ai->ai_addr;
+sockaddr_v6->sin6_port = htons(port);
+} else {
+struct sockaddr_in * sockaddr = (struct sockaddr_in
*)ai->ai_addr;
+sockaddr->sin_port = htons(port);
+}
+ret = bind(fd, (struct sockaddr *)ai->ai_addr,
(int)ai->ai_addrlen);
+if (ret) {
+av_log(ctx, AV_LOG_WARNING,
+"Failed to bind local addr: %s port: %d err: %s\n",
+s->local_addr, s->local_port, gai_strerror(ret));
+}
+}
+}
/* Set the socket's send or receive buffer sizes, if specified.
If unspecified or setting fails, system default is used. */
if (s->recv_buffer_size > 0) {
@@ -129,6 +166,13 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
if (buf == endptr)
s->listen = 1;
}
+if (av_find_info_tag(buf, sizeof(buf), "local_port", p)) {
+s->local_port = strtol(buf, NULL, 10);
+}
+if (av_find_info_tag(buf, sizeof(buf), "local_addr", p)) {
+av_freep(&s->local_addr);
+s->local_addr = av_strndup(buf, strlen(buf));
+}
if (av_find_info_tag(buf, sizeof(buf), "timeout", p)) {
s->rw_timeout = strtol(buf, NULL, 10);
}
--
2.39.2
___
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".
Re: [FFmpeg-devel] [PATCH v2] libavformat: Add ZeroMQ as a protocol option
On Wed, Aug 7, 2019 at 10:22 AM Andriy Gelman wrote: > On Sun, 04. Aug 14:36, Andriy Gelman wrote: > > Changes in v2: > > 1. Replaced zmq_poll with zmq_msg_recv. > > 2. Remove user timeout option as zmq_msg_recv(.., .., ZMQ_DONTWAIT) is > a > > non-blocking call. > > 3. Updated docs. > > > > Andriy > > > diff --git a/libavformat/Makefile b/libavformat/Makefile > > index a434b005a4..4a535429b7 100644 > > --- a/libavformat/Makefile > > +++ b/libavformat/Makefile > > @@ -631,6 +631,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o > > OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o > > OBJS-$(CONFIG_LIBSRT_PROTOCOL) += libsrt.o > > OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o > > +OBJS-$(CONFIG_LIBZMQ_PROTOCOL) > += libzmq.o > > > There is a TAB here, Please remove it > > # libavdevice dependencies > > OBJS-$(CONFIG_IEC61883_INDEV)+= dv.o > > > ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/libsrt: Change latency option to milliseconds
On Wed, Apr 8, 2020 at 3:34 PM pkv wrote: > > Le 08/04/2020 à 3:45 am, Limin Wang a écrit : > > On Wed, Apr 08, 2020 at 02:16:23AM +0200, pkv wrote: > >> Hi > >> > >> Le 08/04/2020 à 12:33 am, Limin Wang a écrit : > >>> On Tue, Apr 07, 2020 at 08:25:44PM +0200, pkv wrote: > Hi > > new patch for latency option following the comments from N. George. > >>> I recall I had submit a patchset for related option incliding latency. > >>> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200331140808.8839-2-lance.lmw...@gmail.com/ > >> hadn't spotted it; why was it not merged ? > >> > >> > >>> Why I haven't change to use AV_OPT_TYPE_DURATION, for the latency can > >>> be used in format srt://:port?latency=?, it's in unit of ms, > >>> in addition, AV_OPT_TYPE_DURATION is in unit of second default, it'll > >>> break the old user. > >> i tested with ffmpeg.exe; the change to > >> > >> AV_OPT_TYPE_DURATION > >> > >> didn't seem to break anything. > >> > >> The default is still set to whatever the libsrt API has set (120 ms > >> for transtype=live). > >> > >> Can you produce code broken by that change ? > > What's your command line? > > I recall If use AV_OPT_TYPE_DURATION for option, the default is in unit > of second if your > > don't add suffix of ms, us. However the old is us, so it'll cause old > user > > setting broken. > > > Ok I get your point. > > here are the commands I tested with: > > ffmpeg.exe -re -i source.mp4 -c copy -f mpegts srt:://dest:port > > and > > ffmpeg.exe -re -i source.mp4 -c copy -f mpegts > srt:://dest:port?latency=40 > > These two don't break anything. > > But indeed > > ffmpeg.exe -re -i source.mp4 -c copy -latency=40 -f mpegts > srt:://dest:port > > is breaking stuff. > > I'll revert the change suggested by N. George in that case. > DO NOT CHANGE, Microsecond is better than millisecond. it's compatible with other ffmpeg options The fault is srt's implementation, not ffmpeg's ___ 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".
Re: [FFmpeg-devel] [PATCH 48/48] fftools/ffmpeg: use av_packet_alloc() to allocate packets
On Sat, Mar 6, 2021 at 12:44 AM James Almer wrote:
> Signed-off-by: James Almer
> ---
> fftools/ffmpeg.c | 318 +++
> fftools/ffmpeg.h | 4 +
> fftools/ffmpeg_opt.c | 5 +-
> 3 files changed, 177 insertions(+), 150 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 2abbc0ff29..46bb014de8 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
>
> @@ -610,9 +611,9 @@ static void ffmpeg_cleanup(int ret)
>
> if (ost->muxing_queue) {
> while (av_fifo_size(ost->muxing_queue)) {
> -AVPacket pkt;
> +AVPacket *pkt;
> av_fifo_generic_read(ost->muxing_queue, &pkt,
> sizeof(pkt), NULL);
>
Should you modify av_fifo_generic_read() for its second arguments( &pkt) as
well?
___
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".
[FFmpeg-devel] Patch: aligin fix
Dear: In doc/example/resampling_audio.c /* buffer is going to be directly written to a rawaudio file, no alignment */ dst_nb_channels = av_get_channel_layout_nb_channels(dst_ch_layout); ret = av_samples_alloc_array_and_samples(&dst_data, &dst_linesize, dst_nb_channels, dst_nb_samples, dst_sample_fmt, 0); if the comment "no alignment" is right, we should change the last parameter of av_samples_alloc_array_and_samples() from 0 to 1. patch is attached. align_fix.diff Description: Binary data ___ 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".
Re: [FFmpeg-devel] Fix x264 SEI offset
Oops
Sent wrong patch, Please use the following:
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 9afaf19547..f78365a4f7 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
for (i = 0; i < nnal; i++) {
/* Don't put the SEI in extradata. */
if (nal[i].i_type == NAL_SEI) {
-av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
+av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
x4->sei_size = nal[i].i_payload;
x4->sei = av_malloc(x4->sei_size);
if (!x4->sei)
On Mon, Jul 26, 2021 at 8:09 PM Jack Waller wrote:
> Dear:
>
> The libavcodec/libx264.c uses the wrong offset to obtain the SEI
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index f78365a4f7..9afaf19547 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
> for (i = 0; i < nnal; i++) {
> /* Don't put the SEI in extradata. */
> if (nal[i].i_type == NAL_SEI) {
> -av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
> +av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
> x4->sei_size = nal[i].i_payload;
> x4->sei = av_malloc(x4->sei_size);
> if (!x4->sei)
>
fix_x264_SEI_offset_2.diff
Description: Binary data
___
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".
[FFmpeg-devel] Fix x264 SEI offset
Dear:
The libavcodec/libx264.c uses the wrong offset to obtain the SEI
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index f78365a4f7..9afaf19547 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
for (i = 0; i < nnal; i++) {
/* Don't put the SEI in extradata. */
if (nal[i].i_type == NAL_SEI) {
-av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
+av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
x4->sei_size = nal[i].i_payload;
x4->sei = av_malloc(x4->sei_size);
if (!x4->sei)
fix_x264_SEI_offset.diff
Description: Binary data
___
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".
[FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores the NULL check to
avoid these problems.
---
libavutil/opt.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c8413fa5e1..9f36dc89a9 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -333,7 +333,13 @@ static int set_string_image_size(void *obj, const AVOption
*o, const char *val,
static int set_string_video_rate(void *obj, const AVOption *o, const char
*val, AVRational *dst)
{
-int ret = av_parse_video_rate(dst, val);
+int ret;
+
+if (!val) {
+av_log(obj, AV_LOG_ERROR, "NULL passed as video rate\n");
+return AVERROR(EINVAL);
+}
+ret = av_parse_video_rate(dst, val);
if (ret < 0)
av_log(obj, AV_LOG_ERROR, "Unable to parse option value \"%s\" as
video rate\n", val);
return ret;
--
2.17.1
___
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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Hello, Apologies for the delay in replying. This patch is not to address a specific problem that currently exists, but rather to restore the robustness to invalid input that previously existed in this function. The motivation for the patch is that we would like to merge a500b975 into our local tree to gain support for gcc 10, but there are concerns about the removal of the null check. av_parse_video_rate() passes its argument directly to strcmp, which would cause undefined behaviour if the argument was NULL. Thanks, Jack On Fri, Jul 31, 2020 at 8:31 PM Michael Niedermayer wrote: > Hi > > On Fri, Jul 31, 2020 at 03:53:56PM +0100, Jack Haughton wrote: > > Commit a500b975 removed NULL input handling from this function, > > moving the check higher up the call tree in one branch. However, > > there is another call to set_string_video_rate() which may pass > > NULL, and future users of the function may not be clear that > > a NULL check is required. This patch restores the NULL check to > > avoid these problems. > > Does this affect something else than the seting based on defaults ? > because the defaults should probably be valid values > or if you disagree, iam curious where the default would be intentionally > invalid > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Breaking DRM is a little like attempting to break through a door even > though the window is wide open and the only thing in the house is a bunch > of things you dont want and which you would get tomorrow for free anyway > -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
A NULL check in av_parse_video_rate() would certainly not be a bad idea. It wouldn't (on its own) restore the NULL input robustness to set_string_video_rate() though, as any error value returned from av_parse_video_rate() would result in val being logged using %s, which is the whole problem that a500b975 was aiming to solve. av_parse_video_rate() is also called from a lot more places (most of which already have an explicit NULL check immediately before the call), so changing the behaviour of that function by adding a NULL check potentially has a lot more knock-on effects than simply restoring the previously existing robustness to set_string_video_rate(), which is also in keeping with the other av_parse_video_rate() callsites. You say that the caller 'should not' pass NULL to set_string_video_rate(). Absolutely, agreed, but the point of checks is to handle unexpected situations. If someone does pass NULL, as of a500b975 the response will be undefined behaviour, where previously it would have been cleanly handled with an explicit error code. I'd contend that this is a bad response. Thanks Jack On Sun, Aug 2, 2020 at 11:28 PM Michael Niedermayer wrote: > On Sun, Aug 02, 2020 at 08:40:27PM +0100, Jack Haughton wrote: > > Hello, > > > > Apologies for the delay in replying. This patch is not to address a > > specific problem that currently exists, but rather to restore the > > robustness to invalid input that previously existed in this function. The > > motivation for the patch is that we would like to merge a500b975 into our > > local tree to gain support for gcc 10, but there are concerns about the > > removal of the null check. av_parse_video_rate() passes its argument > > directly to strcmp, which would cause undefined behaviour if the argument > > was NULL. > > now it makes it even less sense to me. > av_parse_video_rate() doesnt support a NULL argument before or after your > patch, its undefined behaviour either way. > what you change is a private function using that public function. > > Now if you changed the public function to do something specific with a NULL > argument then that would be more robust maybe but not when its done to a > single caller which should not pass NULL there > > thx > > > > > > > Thanks, > > Jack > > > > On Fri, Jul 31, 2020 at 8:31 PM Michael Niedermayer > > > wrote: > > > > > Hi > > > > > > On Fri, Jul 31, 2020 at 03:53:56PM +0100, Jack Haughton wrote: > > > > Commit a500b975 removed NULL input handling from this function, > > > > moving the check higher up the call tree in one branch. However, > > > > there is another call to set_string_video_rate() which may pass > > > > NULL, and future users of the function may not be clear that > > > > a NULL check is required. This patch restores the NULL check to > > > > avoid these problems. > > > > > > Does this affect something else than the seting based on defaults ? > > > because the defaults should probably be valid values > > > or if you disagree, iam curious where the default would be > intentionally > > > invalid > > > > > > thx > > > > > > [...] > > > -- > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > > > Breaking DRM is a little like attempting to break through a door even > > > though the window is wide open and the only thing in the house is a > bunch > > > of things you dont want and which you would get tomorrow for free > anyway > > > > > > > > > -- > > > > Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company > > > > Registered in England with registered office at St John's Innovation > > Centre, Cowley Road, Cambridge, CB4 0WS > > ___ > > 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". > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is what and why we do it that matters, not just one of them. > ___ > 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". -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
I think we're talking past each other. You're asking me to demonstrate a current way in which NULL might be passed to this function. I don't think it's necessary to do that in order for this patch to be a good idea. > Is this about something iam missing or a lib user passing invalidly > setup AVOptions ? (he should fix his code) Absolutely, he should fix his code. But let's say some code gets by code review that has a corner case whereby NULL can be passed. Isn't it better for that condition to be handled cleanly (as it was before a500b975) rather than causing undefined behaviour? Then the error will be reported to the user with a clear error message and can be diagnosed and fixed quickly. Currently, what happens in this case will be implementation-dependent, making it much more difficult to diagnose. To be clear, I do not have a specific case in mind that will currently pass NULL to this function. The point of this patch is to stop relying on all current and future callers to this function always being completely bug-free, but instead to handle any error condition properly, as it is at most of the other av_parse_video_rate callsites. Could you explain why you would not want to do that? Thanks Jack On Mon, Aug 3, 2020 at 11:27 PM Michael Niedermayer wrote: > On Mon, Aug 03, 2020 at 02:07:36PM +0100, Jack Haughton wrote: > > A NULL check in av_parse_video_rate() would certainly not be a bad idea. > It > > wouldn't (on its own) restore the NULL input robustness to > > set_string_video_rate() though, as any error value returned from > > av_parse_video_rate() would result in val being logged using %s, which is > > the whole problem that a500b975 was aiming to solve. > > > > av_parse_video_rate() is also called from a lot more places (most of > which > > already have an explicit NULL check immediately before the call), so > > changing the behaviour of that function by adding a NULL check > potentially > > has a lot more knock-on effects than simply restoring the previously > > existing robustness to set_string_video_rate(), which is also in keeping > > with the other av_parse_video_rate() callsites. > > > > You say that the caller 'should not' pass NULL to > set_string_video_rate(). > > Absolutely, agreed, but the point of checks is to handle unexpected > > situations. > > > If someone does pass NULL, as of a500b975 the response will be > > who is passing NULL in which way ? > this is not a public function > > You can achieve such a NULL input by seting up an invalid AVOption > but you dont seem to speak about that. > > please explain what sort of robustness you want to achieve here > Is this about something iam missing or a lib user passing invalidly > setup AVOptions ? (he should fix his code) or some FFmpeg internal > robustness or what else ? > > > > undefined behaviour, where previously it would have been cleanly handled > > with an explicit error code. I'd contend that this is a bad response. > > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If a bugfix only changes things apparently unrelated to the bug with no > further explanation, that is a good sign that the bugfix is wrong. > ___ > 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". -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores the NULL check to
avoid these problems.
---
libavutil/opt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c8413fa5e1..bcb46451e0 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -333,7 +333,10 @@ static int set_string_image_size(void *obj, const
AVOption *o, const char *val,
static int set_string_video_rate(void *obj, const AVOption *o, const char
*val, AVRational *dst)
{
-int ret = av_parse_video_rate(dst, val);
+int ret;
+
+av_assert0(val);
+ret = av_parse_video_rate(dst, val);
if (ret < 0)
av_log(obj, AV_LOG_ERROR, "Unable to parse option value \"%s\" as
video rate\n", val);
return ret;
--
2.17.0.windows.1
On Wed, Aug 5, 2020 at 2:12 PM Jack Haughton
wrote:
> Fair enough, I agree an assert would be better - I'll send another patch.
>
> I was not intending to advocate for defensive programming - the patch was
> done this way in order to restore the previous behaviour. Although I agree
> with you that the outcome of passing NULL to strcmp is pretty much
> certainly a segmentation fault, the documentation marks it as undefined
> behaviour, which is, well, undefined - and therefore not to be relied upon
> IMO.
>
> Thanks
> Jack
>
> On Tue, Aug 4, 2020 at 2:58 PM Nicolas George wrote:
>
>> Jack Haughton (12020-08-04):
>> > Absolutely, he should fix his code. But let's say some code gets by code
>> > review that has a corner case whereby NULL can be passed. Isn't it
>> better
>> > for that condition to be handled cleanly (as it was before a500b975)
>> rather
>> > than causing undefined behaviour? Then the error will be reported to the
>> > user with a clear error message and can be diagnosed and fixed quickly.
>> > Currently, what happens in this case will be implementation-dependent,
>> > making it much more difficult to diagnose.
>>
>> It depends on what kind of undefined behavior we are talking about.
>> Here, it is about dereferencing NULL, which always result in a
>> segmentation fault, and if we really want to make sure, we can force it
>> with an assert.
>>
>> What you are advocating is a typical example of what is called
>> "defensive programming". When there is some invariant that the code is
>> supposed to enforce (here: a pointer that should not be NULL), defensive
>> programming involves making provisions so that the programs continues
>> even if that invariant is broken.
>>
>> The thing is: defensive programming is almost always wrong. If an
>> invariant is broken, that means there is a bug. We do not know which
>> bug, but there is a bug. And since we do not know what it is, we have to
>> assume the worst is possible: exploitable security issue, silent data
>> corruption.
>>
>> And even if the worst does not happen, defensive programming makes
>> debugging harder: it hides the bugs, let the program seems to work, or
>> it delays the manifestation of the bug, and therefore requires more work
>> to track it. Also note that people will (irrationally) be in more hurry
>> to fix a crash than to fix an error message that looks clean.
>>
>> In this kind of cases, we have to ask ourselves a series of questions:
>>
>> 1. Is it convenient to let the caller pass NULL and have a sane result?
>>→ For free(), yes.
>>→ For av_parse_video_rate(), no, so we go to the next question.
>>
>> 2. Is it easy for the caller to check the validity of the parameter?
>>→ For == NULL, yes.
>>
>> Then the correct way of dealing with it is (1) document "the parameter
>> must not be NULL", (2) make sure it crashes early if the parameter is
>> NULL.
>>
>> Regards,
>>
>> --
>> Nicolas George
>> ___
>> 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".
>
>
>
> --
>
> Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company
>
> Registered in England with registered office at St John's Innovation
> Centre, Cowley Road, Cambridge, CB4 0WS
>
--
Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company
Registered in England with registered office at St John's Innovation
Centre, Cowley Road, Cambridge, CB4 0WS
___
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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Fair enough, I agree an assert would be better - I'll send another patch. I was not intending to advocate for defensive programming - the patch was done this way in order to restore the previous behaviour. Although I agree with you that the outcome of passing NULL to strcmp is pretty much certainly a segmentation fault, the documentation marks it as undefined behaviour, which is, well, undefined - and therefore not to be relied upon IMO. Thanks Jack On Tue, Aug 4, 2020 at 2:58 PM Nicolas George wrote: > Jack Haughton (12020-08-04): > > Absolutely, he should fix his code. But let's say some code gets by code > > review that has a corner case whereby NULL can be passed. Isn't it better > > for that condition to be handled cleanly (as it was before a500b975) > rather > > than causing undefined behaviour? Then the error will be reported to the > > user with a clear error message and can be diagnosed and fixed quickly. > > Currently, what happens in this case will be implementation-dependent, > > making it much more difficult to diagnose. > > It depends on what kind of undefined behavior we are talking about. > Here, it is about dereferencing NULL, which always result in a > segmentation fault, and if we really want to make sure, we can force it > with an assert. > > What you are advocating is a typical example of what is called > "defensive programming". When there is some invariant that the code is > supposed to enforce (here: a pointer that should not be NULL), defensive > programming involves making provisions so that the programs continues > even if that invariant is broken. > > The thing is: defensive programming is almost always wrong. If an > invariant is broken, that means there is a bug. We do not know which > bug, but there is a bug. And since we do not know what it is, we have to > assume the worst is possible: exploitable security issue, silent data > corruption. > > And even if the worst does not happen, defensive programming makes > debugging harder: it hides the bugs, let the program seems to work, or > it delays the manifestation of the bug, and therefore requires more work > to track it. Also note that people will (irrationally) be in more hurry > to fix a crash than to fix an error message that looks clean. > > In this kind of cases, we have to ask ourselves a series of questions: > > 1. Is it convenient to let the caller pass NULL and have a sane result? >→ For free(), yes. >→ For av_parse_video_rate(), no, so we go to the next question. > > 2. Is it easy for the caller to check the validity of the parameter? >→ For == NULL, yes. > > Then the correct way of dealing with it is (1) document "the parameter > must not be NULL", (2) make sure it crashes early if the parameter is > NULL. > > Regards, > > -- > Nicolas George > ___ > 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". -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
[FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores the NULL check to
avoid these problems.
---
libavutil/opt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c8413fa5e1..50bf769cbd 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -333,7 +333,10 @@ static int set_string_image_size(void *obj, const AVOption
*o, const char *val,
static int set_string_video_rate(void *obj, const AVOption *o, const char
*val, AVRational *dst)
{
-int ret = av_parse_video_rate(dst, val);
+int ret;
+
+av_assert0(val);
+ret = av_parse_video_rate(dst, val);
if (ret < 0)
av_log(obj, AV_LOG_ERROR, "Unable to parse option value \"%s\" as
video rate\n", val);
return ret;
--
2.17.1
___
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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Hi Andreas, You're right - apologies. So in fact there was an exchange of one kind of undefined behaviour for another. Thanks Jack On Thu, Aug 6, 2020 at 1:52 PM Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: > Jack Haughton: > > A NULL check in av_parse_video_rate() would certainly not be a bad idea. > It > > wouldn't (on its own) restore the NULL input robustness to > > set_string_video_rate() though, as any error value returned from > > av_parse_video_rate() would result in val being logged using %s, which is > > the whole problem that a500b975 was aiming to solve. > > > > av_parse_video_rate() is also called from a lot more places (most of > which > > already have an explicit NULL check immediately before the call), so > > changing the behaviour of that function by adding a NULL check > potentially > > has a lot more knock-on effects than simply restoring the previously > > existing robustness to set_string_video_rate(), which is also in keeping > > with the other av_parse_video_rate() callsites. > > > > You say that the caller 'should not' pass NULL to > set_string_video_rate(). > > Absolutely, agreed, but the point of checks is to handle unexpected > > situations. If someone does pass NULL, as of a500b975 the response will > be > > undefined behaviour, where previously it would have been cleanly handled > > with an explicit error code. I'd contend that this is a bad response. > > > You are contradicting yourself here: As the commit message of a500b975 > makes clear and as you explain in the first paragraph, a NULL value > would not have been handled cleanly before a500b975: Using NULL for %s > is undefined behaviour, too. Just wanted to mention it because you > repeat this point later in another mail: > > Jack Haughton: > > Isn't it better for that condition to be handled cleanly (as it was > > before a500b975) rather than causing undefined behaviour? > > - Andreas > ___ > 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". -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
[FFmpeg-devel] [PATCH] libavcodec, libavformat: Added DFPWM1a codec and raw format
From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds both a new codec (with encoding and decoding), as well as a raw audio format to be able to read/write the raw files that are most commonly used (as no other container format supports it yet). The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. There's a bit of extra code to convert from unsigned to signed 8-bit audio, as the codec implementation operates on signed data, which FFmpeg doesn't support. The muxers are mostly copied from the PCM demuxer and the raw muxers, as DFPWM is typically stored as raw data. This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there. It will streamline the process for importing audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. One thing I noticed is that this sample file fails to decode to raw: https://samples.ffmpeg.org/ogg/virginradio-three-consecutive-chains.ogg It reports "Application provided invalid, non monotonically increasing dts to muxer in stream 0", which appears to be because the initial timestamp is not 0:00. This affects all raw muxers, including PCM. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 2 + doc/general_contents.texi | 2 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 ++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 138 + libavcodec/dfpwmenc.c | 140 ++ libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- libavformat/Makefile | 2 + libavformat/allformats.c | 2 + libavformat/dfpwmdec.c| 107 + libavformat/rawenc.c | 13 libavformat/version.h | 4 +- 16 files changed, 424 insertions(+), 3 deletions(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c create mode 100644 libavformat/dfpwmdec.c diff --git a/Changelog b/Changelog index 5ad2cef..ec688da 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder and raw muxer/demuxer version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..931cf4b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm*Jack Bruienne dirac*Rostislav Pehlivanov dnxhd*Baptiste Coudurier dolby_e* foo86 @@ -415,6 +416,7 @@ Muxers/Demuxers: dashde
Re: [FFmpeg-devel] [PATCH] libavcodec, libavformat: Added DFPWM1a codec and raw format
Thanks for looking over the patch. I used git format-patch to make the email and then sent it with Thunderbird; it appears that the command on the website doesn't put the patch in an attachment. I'll be adding --attach for future patches to fix this. I will be sending split updated patches fixing the issues you mentioned promptly. On 2/25/22 03:15, Paul B Mahol wrote: On Fri, Feb 25, 2022 at 02:54:35AM -0500, Jack Bruienne wrote: From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds both a new codec (with encoding and decoding), as well as a raw audio format to be able to read/write the raw files that are most commonly used (as no other container format supports it yet). The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. There's a bit of extra code to convert from unsigned to signed 8-bit audio, as the codec implementation operates on signed data, which FFmpeg doesn't support. The muxers are mostly copied from the PCM demuxer and the raw muxers, as DFPWM is typically stored as raw data. This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there. It will streamline the process for importing audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. One thing I noticed is that this sample file fails to decode to raw: https://samples.ffmpeg.org/ogg/virginradio-three-consecutive-chains.ogg It reports "Application provided invalid, non monotonically increasing dts to muxer in stream 0", which appears to be because the initial timestamp is not 0:00. This affects all raw muxers, including PCM. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 2 + doc/general_contents.texi | 2 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 ++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 138 + libavcodec/dfpwmenc.c | 140 ++ libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- libavformat/Makefile | 2 + libavformat/allformats.c | 2 + libavformat/dfpwmdec.c| 107 + libavformat/rawenc.c | 13 libavformat/version.h | 4 +- 16 files changed, 424 insertions(+), 3 deletions(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c create mode 100644 libavformat/dfpwmdec.c diff --git a/Changelog b/Changelog index 5ad2cef..ec688da 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder and raw muxer/demuxer Keep empty line here above and everywhere else you had removed them. Is patch corrupted somehow? Just attach file. And split d
[FFmpeg-devel] [PATCH v2 1/2] libavcodec: Added DFPWM1a codec
From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds a new codec (with encoding and decoding) for DFPWM1a. The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there. It will streamline the process for importing audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 +++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 129 ++ libavcodec/dfpwmenc.c | 123 libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- 11 files changed, 270 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm* Jack Bruienne dirac*Rostislav Pehlivanov dnxhd*Baptiste Coudurier dolby_e* foo86 diff --git a/doc/general_contents.texi b/doc/general_contents.texi index df1692c..14aeaed 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -1194,6 +1194,7 @@ following image formats are supported: @item CRI HCA@tab @tab X @item Delphine Software International CIN audio @tab @tab X @tab Codec used in Delphine Software International games. +@item DFPWM @tab X @tab X @item Digital Speech Standard - Standard Play mode (DSS SP) @tab @tab X @item Discworld II BMV Audio @tab @tab X @item COOK @tab @tab X diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 6076b4a..7474220 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -289,6 +289,8 @@ OBJS-$(CONFIG_DERF_DPCM_DECODER) += dpcm.o OBJS-$(CONFIG_DIRAC_DECODER) += diracdec.o dirac.o diracdsp.o diractab.o \ dirac_arith.o dirac_dwt.o dirac_vlc.o OBJS-$(CONFIG_DFA_DECODER) += dfa.o +OBJS-$(CONFIG_DFPWM_DECODER) += dfpwmdec.o +OBJS-$(CONFIG_DFP
[FFmpeg-devel] [PATCH v2 2/2] libavformat: Add DFPWM raw format
This patch builds on my previous DFPWM codec patch, adding a raw
audio format to be able to read/write the raw files that are most commonly
used (as no other container format supports it yet).
The muxers are mostly copied from the PCM demuxer and the raw muxers, as
DFPWM is typically stored as raw data.
Please see the previous patch for more information on DFPWM.
Signed-off-by: Jack Bruienne
---
Changelog | 2 +-
MAINTAINERS | 1 +
doc/general_contents.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/dfpwmdec.c| 107 ++
libavformat/rawenc.c | 13 +
libavformat/version.h | 4 +-
8 files changed, 129 insertions(+), 3 deletions(-)
create mode 100644 libavformat/dfpwmdec.c
diff --git a/Changelog b/Changelog
index 5170a6a..ec688da 100644
--- a/Changelog
+++ b/Changelog
@@ -4,7 +4,7 @@ releases are sorted from youngest to oldest.
version 5.1:
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
-- DFPWM audio encoder/decoder
+- DFPWM audio encoder/decoder and raw muxer/demuxer
version 5.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 57b6f33..931cf4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -416,6 +416,7 @@ Muxers/Demuxers:
dashdec.c Steven Liu
dashenc.c Karthick Jeyapal
daud.cReimar Doeffinger
+ dfpwmdec.cJack Bruienne
dss.c Oleksij Rempel
dtsdec.c foo86
dtshddec.cPaul B Mahol
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 14aeaed..fcd9da1 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -578,6 +578,7 @@ library:
@item raw aptX @tab X @tab X
@item raw aptX HD @tab X @tab X
@item raw Chinese AVS video @tab X @tab X
+@item raw DFPWM @tab X @tab X
@item raw Dirac @tab X @tab X
@item raw DNxHD @tab X @tab X
@item raw DTS @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6566e40..b89073a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -165,6 +165,8 @@ OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
OBJS-$(CONFIG_DERF_DEMUXER) += derf.o pcm.o
OBJS-$(CONFIG_DFA_DEMUXER) += dfa.o
+OBJS-$(CONFIG_DFPWM_DEMUXER) += dfpwmdec.o pcm.o
+OBJS-$(CONFIG_DFPWM_MUXER) += rawenc.o
OBJS-$(CONFIG_DHAV_DEMUXER) += dhav.o
OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o
OBJS-$(CONFIG_DIRAC_MUXER) += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d066a77..587ad59 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -124,6 +124,8 @@ extern const AVOutputFormat ff_daud_muxer;
extern const AVInputFormat ff_dcstr_demuxer;
extern const AVInputFormat ff_derf_demuxer;
extern const AVInputFormat ff_dfa_demuxer;
+extern const AVInputFormat ff_dfpwm_demuxer;
+extern const AVOutputFormat ff_dfpwm_muxer;
extern const AVInputFormat ff_dhav_demuxer;
extern const AVInputFormat ff_dirac_demuxer;
extern const AVOutputFormat ff_dirac_muxer;
diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
new file mode 100644
index 000..ad5bfa5
--- /dev/null
+++ b/libavformat/dfpwmdec.c
@@ -0,0 +1,107 @@
+/*
+ * RAW PCM demuxers
+ * Copyright (c) 2002 Fabrice Bellard
+ * Copyright (c) 2022 Jack Bruienne
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "internal.h"
+#include "pcm.h"
+#include "libavutil/log.h"
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+
+typedef struct DFPWMAudioDemuxerContext {
+AVClass *class;
+int sample_rate;
+} DFPWMAudioDemuxerContext;
+
+static int dfpwm_read_header(AVFormatContext *s)
+{
+DFPWMAudioDemuxerContext *s1 = s->priv_data;
+
Re: [FFmpeg-devel] [PATCH v2 1/2] libavcodec: Added DFPWM1a codec
Sorry, I forgot to run make fate on the split patches, and I used the wrong capabilities for the decoder. I have attached a modified patch that removes AV_CODEC_CAP_VARIABLE_FRAME_SIZE from the decoder capabilities. Let me know if you'd like a full v3 patch email instead. On 2/25/22 18:43, Jack Bruienne wrote: From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds a new codec (with encoding and decoding) for DFPWM1a. The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there. It will streamline the process for importing audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c | 2 + libavcodec/codec_desc.c | 7 +++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 129 ++ libavcodec/dfpwmenc.c | 123 libavcodec/utils.c | 2 + libavcodec/version.h | 2 +- 11 files changed, 270 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm*Jack Bruienne dirac*Rostislav Pehlivanov dnxhd*Baptiste Coudurier dolby_e* foo86 diff --git a/doc/general_contents.texi b/doc/general_contents.texi index df1692c..14aeaed 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -1194,6 +1194,7 @@ following image formats are supported: @item CRI HCA@tab @tab X @item Delphine Software International CIN audio @tab @tab X @tab Codec used in Delphine Software International games. +@item DFPWM @tab X @tab X @item Digital Speech Standard - Standard Play mode (DSS SP) @tab @tab X @item Discworld II BMV Audio @tab @tab X @item COOK @tab @tab X diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 6076b4a..7474220 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -289,6 +289,8 @@ OBJS-$(CONFIG_
[FFmpeg-devel] [PATCH v3 1/2] libavcodec: Added DFPWM1a codec
From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds a new codec (with encoding and decoding) for DFPWM1a. The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there. It will streamline the process for importing audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. Changes since the prior v2 patch: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 +++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 129 ++ libavcodec/dfpwmenc.c | 123 libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- 11 files changed, 270 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm*Jack Bruienne dirac*Rostislav Pehlivanov dnxhd*Baptiste Coudurier dolby_e* foo86 diff --git a/doc/general_contents.texi b/doc/general_contents.texi index df1692c..14aeaed 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -1194,6 +1194,7 @@ following image formats are supported: @item CRI HCA@tab @tab X @item Delphine Software International CIN audio @tab @tab X @tab Codec used in Delphine Software International games. +@item DFPWM @tab X @tab X @item Digital Speech Standard - Standard Play mode (DSS SP) @tab @tab X @item Discworld II BMV Audio @tab @tab X @item COOK @tab @tab X diff --git a/libavcodec/Makefile b/libavcode
[FFmpeg-devel] [PATCH v4 1/2] libavcodec: Added DFPWM1a codec
From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds a new codec (with encoding and decoding) for DFPWM1a. The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. To clarify, the codec does not have a specific sample rate - it is provided by the container (or user), which is typically 48000, but has also been known to be 32768. The codec does not specify channel info either, and it's pretty much always used with one mono channel. However, since it appears that libavcodec expects both sample rate and channel count to be handled by either the codec or container, I have made the decision to allow multiple channels interleaved, which as far as I know has never been used, but it works fine here nevertheless. The accompanying raw format has a channels option to set this. (I expect most users of this will not use multiple channels, but it remains an option just in case.) This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there, and even fewer decoders. It will streamline the process for importing and listening to audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. Changes since v3: Added support for multiple interleaved channels, and cleaned up the code a bunch. Changes since v2: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 +++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 127 ++ libavcodec/dfpwmenc.c | 121 libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- 11 files changed, 266 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm*
[FFmpeg-devel] [PATCH v4 2/2] libavformat: Add DFPWM raw format
This patch builds on my previous DFPWM codec patch, adding a raw
audio format to be able to read/write the raw files that are most commonly
used (as no other container format supports it yet).
The muxers are mostly copied from the PCM demuxer and the raw muxers, as
DFPWM is typically stored as raw data.
Please see the previous patch for more information on DFPWM.
Changes since v2/v3:
Removed unused MIME parsing code, and added channels option.
Signed-off-by: Jack Bruienne
---
Changelog | 2 +-
MAINTAINERS | 1 +
doc/general_contents.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/dfpwmdec.c| 82 +++
libavformat/rawenc.c | 13 +++
libavformat/version.h | 4 +-
8 files changed, 104 insertions(+), 3 deletions(-)
create mode 100644 libavformat/dfpwmdec.c
diff --git a/Changelog b/Changelog
index 5170a6a..ec688da 100644
--- a/Changelog
+++ b/Changelog
@@ -4,7 +4,7 @@ releases are sorted from youngest to oldest.
version 5.1:
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
-- DFPWM audio encoder/decoder
+- DFPWM audio encoder/decoder and raw muxer/demuxer
version 5.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 57b6f33..931cf4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -416,6 +416,7 @@ Muxers/Demuxers:
dashdec.c Steven Liu
dashenc.c Karthick Jeyapal
daud.cReimar Doeffinger
+ dfpwmdec.cJack Bruienne
dss.c Oleksij Rempel
dtsdec.c foo86
dtshddec.cPaul B Mahol
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 14aeaed..fcd9da1 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -578,6 +578,7 @@ library:
@item raw aptX @tab X @tab X
@item raw aptX HD @tab X @tab X
@item raw Chinese AVS video @tab X @tab X
+@item raw DFPWM @tab X @tab X
@item raw Dirac @tab X @tab X
@item raw DNxHD @tab X @tab X
@item raw DTS @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6566e40..b89073a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -165,6 +165,8 @@ OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
OBJS-$(CONFIG_DERF_DEMUXER) += derf.o pcm.o
OBJS-$(CONFIG_DFA_DEMUXER) += dfa.o
+OBJS-$(CONFIG_DFPWM_DEMUXER) += dfpwmdec.o pcm.o
+OBJS-$(CONFIG_DFPWM_MUXER) += rawenc.o
OBJS-$(CONFIG_DHAV_DEMUXER) += dhav.o
OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o
OBJS-$(CONFIG_DIRAC_MUXER) += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d066a77..587ad59 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -124,6 +124,8 @@ extern const AVOutputFormat ff_daud_muxer;
extern const AVInputFormat ff_dcstr_demuxer;
extern const AVInputFormat ff_derf_demuxer;
extern const AVInputFormat ff_dfa_demuxer;
+extern const AVInputFormat ff_dfpwm_demuxer;
+extern const AVOutputFormat ff_dfpwm_muxer;
extern const AVInputFormat ff_dhav_demuxer;
extern const AVInputFormat ff_dirac_demuxer;
extern const AVOutputFormat ff_dirac_muxer;
diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
new file mode 100644
index 000..d5833f8
--- /dev/null
+++ b/libavformat/dfpwmdec.c
@@ -0,0 +1,82 @@
+/*
+ * RAW PCM demuxers
+ * Copyright (c) 2002 Fabrice Bellard
+ * Copyright (c) 2022 Jack Bruienne
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "internal.h"
+#include "pcm.h"
+#include "libavutil/log.h"
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+
+typedef struct DFPWMAudioDemuxerContext {
+AVClass *class;
+int sample_rate;
+int channels;
+} DFPWMAudioDemuxerContext;
+
+static int dfpwm_re
[FFmpeg-devel] [PATCH v5 1/2] libavcodec: Added DFPWM1a codec
From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds a new codec (with encoding and decoding) for DFPWM1a. The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. To clarify, the codec does not have a specific sample rate - it is provided by the container (or user), which is typically 48000, but has also been known to be 32768. The codec does not specify channel info either, and it's pretty much always used with one mono channel. However, since it appears that libavcodec expects both sample rate and channel count to be handled by either the codec or container, I have made the decision to allow multiple channels interleaved, which as far as I know has never been used, but it works fine here nevertheless. The accompanying raw format has a channels option to set this. (I expect most users of this will not use multiple channels, but it remains an option just in case.) This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there, and even fewer decoders. It will streamline the process for importing and listening to audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. Changes since v4: Fixed missing channel check in decoder. Changes since v3: Added support for multiple interleaved channels, and cleaned up the code a bunch. Changes since v2: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 ++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 133 ++ libavcodec/dfpwmenc.c | 121 ++ libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- 11 files changed, 272 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca*
[FFmpeg-devel] [PATCH v5 2/2] libavformat: Add DFPWM raw format
This patch builds on my previous DFPWM codec patch, adding a raw audio format to be able to read/write the raw files that are most commonly used (as no other container format supports it yet). The muxers are mostly copied from the PCM demuxer and the raw muxers, as DFPWM is typically stored as raw data. Note on the channels argument: The -ac argument can only be used as an alias if -f dfpwm is passed. If missing, -ac has no effect. The -channels argument will work regardless of the presence of -f. Please see the previous patch for more information on DFPWM. Changes since v4: Fixed descriptions of formats. Changes since v2/v3: Removed unused MIME parsing code, and added channels option. Signed-off-by: Jack Bruienne --- Changelog | 2 +- MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavformat/Makefile | 2 + libavformat/allformats.c | 2 + libavformat/dfpwmdec.c| 82 +++ libavformat/rawenc.c | 13 +++ libavformat/version.h | 4 +- 8 files changed, 104 insertions(+), 3 deletions(-) create mode 100644 libavformat/dfpwmdec.c diff --git a/Changelog b/Changelog index 5170a6a..ec688da 100644 --- a/Changelog +++ b/Changelog @@ -4,7 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel -- DFPWM audio encoder/decoder +- DFPWM audio encoder/decoder and raw muxer/demuxer version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index 57b6f33..931cf4b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -416,6 +416,7 @@ Muxers/Demuxers: dashdec.c Steven Liu dashenc.c Karthick Jeyapal daud.cReimar Doeffinger + dfpwmdec.cJack Bruienne dss.c Oleksij Rempel dtsdec.c foo86 dtshddec.cPaul B Mahol diff --git a/doc/general_contents.texi b/doc/general_contents.texi index 14aeaed..fcd9da1 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -578,6 +578,7 @@ library: @item raw aptX @tab X @tab X @item raw aptX HD @tab X @tab X @item raw Chinese AVS video @tab X @tab X +@item raw DFPWM @tab X @tab X @item raw Dirac @tab X @tab X @item raw DNxHD @tab X @tab X @item raw DTS @tab X @tab X diff --git a/libavformat/Makefile b/libavformat/Makefile index 6566e40..b89073a 100644 --- a/libavformat/Makefile +++ b/libavformat/Makefile @@ -165,6 +165,8 @@ OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o OBJS-$(CONFIG_DERF_DEMUXER) += derf.o pcm.o OBJS-$(CONFIG_DFA_DEMUXER) += dfa.o +OBJS-$(CONFIG_DFPWM_DEMUXER) += dfpwmdec.o pcm.o +OBJS-$(CONFIG_DFPWM_MUXER) += rawenc.o OBJS-$(CONFIG_DHAV_DEMUXER) += dhav.o OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o OBJS-$(CONFIG_DIRAC_MUXER) += rawenc.o diff --git a/libavformat/allformats.c b/libavformat/allformats.c index d066a77..587ad59 100644 --- a/libavformat/allformats.c +++ b/libavformat/allformats.c @@ -124,6 +124,8 @@ extern const AVOutputFormat ff_daud_muxer; extern const AVInputFormat ff_dcstr_demuxer; extern const AVInputFormat ff_derf_demuxer; extern const AVInputFormat ff_dfa_demuxer; +extern const AVInputFormat ff_dfpwm_demuxer; +extern const AVOutputFormat ff_dfpwm_muxer; extern const AVInputFormat ff_dhav_demuxer; extern const AVInputFormat ff_dirac_demuxer; extern const AVOutputFormat ff_dirac_muxer; diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c new file mode 100644 index 000..85d9b61 --- /dev/null +++ b/libavformat/dfpwmdec.c @@ -0,0 +1,82 @@ +/* + * RAW PCM demuxers + * Copyright (c) 2002 Fabrice Bellard + * Copyright (c) 2022 Jack Bruienne + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavutil/avstring.h" +#include "avformat.h" +#include "internal.h" +#include "pcm.h" +#include "libavutil
[FFmpeg-devel] [PATCH v6 1/2] libavcodec: Added DFPWM1a codec
From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds a new codec (with encoding and decoding) for DFPWM1a. The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. To clarify, the codec does not have a specific sample rate - it is provided by the container (or user), which is typically 48000, but has also been known to be 32768. The codec does not specify channel info either, and it's pretty much always used with one mono channel. However, since it appears that libavcodec expects both sample rate and channel count to be handled by either the codec or container, I have made the decision to allow multiple channels interleaved, which as far as I know has never been used, but it works fine here nevertheless. The accompanying raw format has a channels option to set this. (I expect most users of this will not use multiple channels, but it remains an option just in case.) This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there, and even fewer decoders. It will streamline the process for importing and listening to audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. Changes since v5: Moved channel check to init, and added sample size check in decoder. Changes since v4: Fixed missing channel check in decoder. Changes since v3: Added support for multiple interleaved channels, and cleaned up the code a bunch. Changes since v2: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 ++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 134 ++ libavcodec/dfpwmenc.c | 121 ++ libavcodec/utils.c| 2 + libavcodec/version.h | 4 +- 11 files changed, 274 insertions(+), 2 deletions(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger
Re: [FFmpeg-devel] [PATCH v6 1/2] libavcodec: Added DFPWM1a codec
On 3/7/22 06:03, Tomas Härdin wrote: tor 2022-03-03 klockan 10:44 -0500 skrev Jack Bruienne: From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one- pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post- processing filters to make the stream more listenable. This sounds similar to something I wrote for the Atari 2600 a number of years ago (https://www.pouet.net/prod.php?which=59283 ) I found an encoder online for DFPWM, and it seems to suffer from the same "beeping" that my debeeping hack fixes (suppressing 0xAA and 0x55 bytes). Perhaps a similar hack could be useful in dfpwmenc.c I'm curious how this works. Do you just cut out those bytes from the encoder output, or is it modified in some way? Wouldn't removing the data entirely eventually cause much of the audio to be lost? It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds a new codec (with encoding and decoding) for DFPWM1a. The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. To clarify, the codec does not have a specific sample rate - it is provided by the container (or user), which is typically 48000, but has also been known to be 32768. The codec does not specify channel info either, and it's pretty much always used with one mono channel. However, since it appears that libavcodec expects both sample rate and channel count to be handled by either the codec or container, I have made the decision to allow multiple channels interleaved, which as far as I know has never been used, but it works fine here nevertheless. From experience it's usually better to be strict when it comes to stuff like this. The ComputerCraft people should work out a standard for this, preferably a container. We've had a similar problem in FreeDV where which codec was being used was implicit most of the time, which has been resolved with the .c2 format. I think the best standardized container for DFPWM will be WAV. I'll have to figure out the best place to properly standardize this, but one first step may be to implement this in CC directly. Unfortunately, ComputerCraft is currently without a maintainer - the previous one stepped down in December, and no changes are being made outside of critical bugfixes. I do hope to pick up development in the future, and I already run a reimplementation of the mod outside Minecraft, but as it stands today, getting this to be picked up by users will be quite difficult. However, I do also maintain my own audio processing library AUKit, which now includes support for DFPWM in WAV. Since CC only has a basic raw DFPWM player built-in (which strictly requires 48kHz mono audio), many users turn to it to play more complex formats like WAV with a different sample rate, FLAC, etc. This may be a decent start, but it's far from having full support built-in. I'll see if I can get in contact with the owner of the DFPWM wiki page. This will be especially important if this patch gets merged, as people likely won't see that you can use FFmpeg on those pages. I am able to submit pull requests to the ComputerCraft documentation site, however, so I'm able to get changes made there much easier. In the meantime, I've made a sort-of RFC for the format:https://gist.github.com/MCJack123/90c24b64c8e626c7f130b57e9800962c --- Changelog | 1 + MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c | 2 + libavcodec/codec_desc.c | 7 ++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 134 ++ libavcodec/dfpwmenc.c | 121 ++ libavcodec/utils.c | 2 + libavcodec/version.h | 4 +- 11 files changed, 274 insertions(+), 2 deletions(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c Patch doesn't apply on current master (e645a1d) I'll update the patch to apply to the current master, but I feel like by the time this next gets reviewed master may break again. Should I just keep updating the patch to master and resubmitting whenever I notice a new commit breaks it? /Tomas __
[FFmpeg-devel] [PATCH v7 1/3] libavcodec: Added DFPWM1a codec
From the wiki page (https://wiki.vexatos.com/dfpwm): DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec created by Ben “GreaseMonkey” Russell in 2012, originally to be used as a voice codec for asiekierka's pixmess, a C remake of 64pixels. It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding creates a high-pitched whine, it is often followed by some post-processing filters to make the stream more listenable. It has recently gained popularity through the ComputerCraft mod for Minecraft, which added support for audio through this codec, as well as the Computronics expansion which preceeded the official support. These both implement the slightly adjusted 1a version of the codec, which is the version I have chosen for this patch. This patch adds a new codec (with encoding and decoding) for DFPWM1a. The codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. To clarify, the codec does not have a specific sample rate - it is provided by the container (or user), which is typically 48000, but has also been known to be 32768. The codec does not specify channel info either, and it's pretty much always used with one mono channel. However, since it appears that libavcodec expects both sample rate and channel count to be handled by either the codec or container, I have made the decision to allow multiple channels interleaved, which as far as I know has never been used, but it works fine here nevertheless. The accompanying raw format has a channels option to set this. (I expect most users of this will not use multiple channels, but it remains an option just in case.) This patch will be highly useful to ComputerCraft developers who are working with audio, as it is the standard format for audio, and there are few user-friendly encoders out there, and even fewer decoders. It will streamline the process for importing and listening to audio, replacing the need to write code or use tools that require very specific input formats. You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test out DFPWM playback. To use it, run the program and type this command: "attach left speaker" Then run "speaker play " for each file. The app runs in a sandbox, so files have to be transferred in first; the easiest way to do this is to simply drag the file on the window. (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.) Sample DFPWM files can be generated with an online tool at https://music.madefor.cc. This is the current best way to encode DFPWM files. Simply drag an audio file onto the page, and it will encode it, giving a download link on the page. I've made sure to update all of the docs as per Developer§7, and I've tested it as per section 8. Test files encoded to DFPWM play correctly in ComputerCraft, and other files that work in CC are correctly decoded. I have also verified that corrupt files do not crash the decoder - this should theoretically not be an issue as the result size is constant with respect to the input size. Changes since v5: Moved channel check to init, and added sample size check in decoder. Changes since v4: Fixed missing channel check in decoder. Changes since v3: Added support for multiple interleaved channels, and cleaned up the code a bunch. Changes since v2: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 ++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 134 ++ libavcodec/dfpwmenc.c | 121 ++ libavcodec/utils.c| 2 + 10 files changed, 272 insertions(+) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 3af8aa0..f3249fe 100644 --- a/Changelog +++ b/Changelog @@ -5,6 +5,7 @@ version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel - pcm-bluray encoder +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca*
[FFmpeg-devel] [PATCH v7 2/3] libavformat: Add DFPWM raw format
This patch builds on my previous DFPWM codec patch, adding a raw
audio format to be able to read/write the raw files that are most commonly
used (as no other container format supports it yet).
The muxers are mostly copied from the PCM demuxer and the raw muxers, as
DFPWM is typically stored as raw data.
Please see the previous patch for more information on DFPWM.
Changes since v4:
Fixed descriptions of formats.
Changes since v2/v3:
Removed unused MIME parsing code, and added channels option.
Signed-off-by: Jack Bruienne
---
Changelog | 2 +-
MAINTAINERS | 1 +
doc/general_contents.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/dfpwmdec.c| 82 +++
libavformat/rawenc.c | 13 +++
libavformat/version.h | 4 +-
8 files changed, 104 insertions(+), 3 deletions(-)
create mode 100644 libavformat/dfpwmdec.c
diff --git a/Changelog b/Changelog
index f3249fe..ac614f8 100644
--- a/Changelog
+++ b/Changelog
@@ -5,7 +5,7 @@ version 5.1:
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
- pcm-bluray encoder
-- DFPWM audio encoder/decoder
+- DFPWM audio encoder/decoder and raw muxer/demuxer
version 5.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 57b6f33..931cf4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -416,6 +416,7 @@ Muxers/Demuxers:
dashdec.c Steven Liu
dashenc.c Karthick Jeyapal
daud.cReimar Doeffinger
+ dfpwmdec.cJack Bruienne
dss.c Oleksij Rempel
dtsdec.c foo86
dtshddec.cPaul B Mahol
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 14aeaed..fcd9da1 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -578,6 +578,7 @@ library:
@item raw aptX @tab X @tab X
@item raw aptX HD @tab X @tab X
@item raw Chinese AVS video @tab X @tab X
+@item raw DFPWM @tab X @tab X
@item raw Dirac @tab X @tab X
@item raw DNxHD @tab X @tab X
@item raw DTS @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 16d019d..322c8e7 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -166,6 +166,8 @@ OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
OBJS-$(CONFIG_DERF_DEMUXER) += derf.o pcm.o
OBJS-$(CONFIG_DFA_DEMUXER) += dfa.o
+OBJS-$(CONFIG_DFPWM_DEMUXER) += dfpwmdec.o pcm.o
+OBJS-$(CONFIG_DFPWM_MUXER) += rawenc.o
OBJS-$(CONFIG_DHAV_DEMUXER) += dhav.o
OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o
OBJS-$(CONFIG_DIRAC_MUXER) += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d066a77..587ad59 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -124,6 +124,8 @@ extern const AVOutputFormat ff_daud_muxer;
extern const AVInputFormat ff_dcstr_demuxer;
extern const AVInputFormat ff_derf_demuxer;
extern const AVInputFormat ff_dfa_demuxer;
+extern const AVInputFormat ff_dfpwm_demuxer;
+extern const AVOutputFormat ff_dfpwm_muxer;
extern const AVInputFormat ff_dhav_demuxer;
extern const AVInputFormat ff_dirac_demuxer;
extern const AVOutputFormat ff_dirac_muxer;
diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
new file mode 100644
index 000..85d9b61
--- /dev/null
+++ b/libavformat/dfpwmdec.c
@@ -0,0 +1,82 @@
+/*
+ * RAW PCM demuxers
+ * Copyright (c) 2002 Fabrice Bellard
+ * Copyright (c) 2022 Jack Bruienne
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "internal.h"
+#include "pcm.h"
+#include "libavutil/log.h"
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+
+typedef struct DFPWMAudioDemuxerContext {
+AVClass *class;
+int sample_rate;
+int channels;
+} DFPWMA
[FFmpeg-devel] [PATCH v7 3/3] libavformat: Added DFPWM WAV container support
This commit adds support for storing DFPWM audio in a WAV container.
It uses the WAVEFORMATEXTENSIBLE structure, following these conventions:
https://gist.github.com/MCJack123/90c24b64c8e626c7f130b57e9800962c
The implementation is very simple: it just adds the GUID to the list of
WAV GUIDs, and modifies the WAV muxer to always use WAVEFORMATEXTENSIBLE
format with that GUID.
This creates a standard container format for DFPWM besides raw data.
It will allow users to transfer DFPWM audio in a standard container
format, with the sample rate and channel count contained in the file
as opposed to being an external parameter as in the raw format.
This format is already supported in my AUKit library, which is the CC
analog to libav (albeit much smaller). Support in other applications is TBD.
Signed-off-by: Jack Bruienne
---
libavformat/riff.c| 3 +++
libavformat/riffenc.c | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 0c19d3f..f098c1d 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -587,6 +587,8 @@ const AVCodecTag ff_codec_wav_tags[] = {
{ AV_CODEC_ID_AAC, 0xA106 },
{ AV_CODEC_ID_SPEEX, 0xA109 },
{ AV_CODEC_ID_FLAC,0xF1AC },
+/* DFPWM does not have an assigned format tag; it uses a GUID in WAVEFORMATEX instead */
+{ AV_CODEC_ID_DFPWM, 0xFFFE },
{ AV_CODEC_ID_ADPCM_SWF, ('S' << 8) + 'F' },
/* HACK/FIXME: Does Vorbis in WAV/AVI have an (in)official ID? */
{ AV_CODEC_ID_VORBIS, ('V' << 8) + 'o' },
@@ -637,5 +639,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
{ AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB, 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
{ AV_CODEC_ID_MP2, { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF, 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
{ AV_CODEC_ID_ADPCM_AGM,{ 0x82, 0xEC, 0x1F, 0x6A, 0xCA, 0xDB, 0x19, 0x45, 0xBD, 0xE7, 0x56, 0xD3, 0xB3, 0xEF, 0x98, 0x1D } },
+{ AV_CODEC_ID_DFPWM,{ 0x3A, 0xC1, 0xFA, 0x38, 0x81, 0x1D, 0x43, 0x61, 0xA4, 0x0D, 0xCE, 0x53, 0xCA, 0x60, 0x7C, 0xD1 } },
{ AV_CODEC_ID_NONE }
};
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index ffccfa3..96750e7 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -81,7 +81,7 @@ int ff_put_wav_header(AVFormatContext *s, AVIOContext *pb,
par->channels == 1 && par->channel_layout && par->channel_layout != AV_CH_LAYOUT_MONO ||
par->channels == 2 && par->channel_layout && par->channel_layout != AV_CH_LAYOUT_STEREO ||
par->sample_rate > 48000 ||
- par->codec_id == AV_CODEC_ID_EAC3 ||
+ par->codec_id == AV_CODEC_ID_EAC3 || par->codec_id == AV_CODEC_ID_DFPWM ||
av_get_bits_per_sample(par->codec_id) > 16;
if (waveformatextensible)
@@ -188,7 +188,7 @@ int ff_put_wav_header(AVFormatContext *s, AVIOContext *pb,
/* dwChannelMask */
avio_wl32(pb, write_channel_mask ? par->channel_layout : 0);
/* GUID + next 3 */
-if (par->codec_id == AV_CODEC_ID_EAC3) {
+if (par->codec_id == AV_CODEC_ID_EAC3 || par->codec_id == AV_CODEC_ID_DFPWM) {
ff_put_guid(pb, ff_get_codec_guid(par->codec_id, ff_codec_wav_guids));
} else {
avio_wl32(pb, par->codec_tag);
___
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".
Re: [FFmpeg-devel] Possibly a little bug in af_loudnorm.c
Please check the code:line 209 if (c == 0 || fabs(buf[index + c]) > max_peak) max_peak = fabs(buf[index + c]); 'max_peak' is initialized. On Sat, Aug 20, 2022 at 5:39 PM jagad hariseno wrote: > Hi All, > > at af_loudnorm.c in line number 188: > double this, next, max_peak; > > max_peak is not initialized with 0. and could be contains any value or > noise. > I could be wrong but I think init with 0. should be better: > > double this, next, max_peak=0.; > > Best Regards > > jagad. > ___ > 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". > ___ 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".
[FFmpeg-devel] [PATCH] avcodec: Fix time reporting for DFPWM streams
This adds the exact bits per sample for DFPWM to
av_get_exact_bits_per_sample.
Previously, the DTS and PTS were set to 0 because the codec never
reported them, but adding this allows libavformat to automatically
set DTS and PTS from the byte position of the stream.
Signed-off-by: Jack Bruienne
---
libavcodec/utils.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index eb7e505a..940f25fe 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -495,6 +495,8 @@ const char *avcodec_profile_name(enum AVCodecID codec_id, int profile)
int av_get_exact_bits_per_sample(enum AVCodecID codec_id)
{
switch (codec_id) {
+case AV_CODEC_ID_DFPWM:
+return 1;
case AV_CODEC_ID_8SVX_EXP:
case AV_CODEC_ID_8SVX_FIB:
case AV_CODEC_ID_ADPCM_ARGO:
___
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".
[FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
The `dec_ctx->time_base` was incorrectly default set to 0/60, while
`enc_ctx->time_base` was derived from `dec_ctx->framerate`. This
mismatch could cause incorrect video duration in the output.
This patch aligns `enc_ctx->time_base` with `dec_ctx->time_base` to
prevent rescaling issues and ensure correct video duration.
Signed-off-by: Jack Lau
---
doc/examples/transcoding.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 013f89fc7d..847bdb7e1a 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -172,7 +172,7 @@ static int open_output_file(const char *filename)
else
enc_ctx->pix_fmt = dec_ctx->pix_fmt;
/* video time_base can be set to whatever is handy and
supported by encoder */
-enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
+enc_ctx->time_base = dec_ctx->time_base;
} else {
enc_ctx->sample_rate = dec_ctx->sample_rate;
ret = av_channel_layout_copy(&enc_ctx->ch_layout,
&dec_ctx->ch_layout);
@@ -180,7 +180,7 @@ static int open_output_file(const char *filename)
return ret;
/* take first format from list of supported formats */
enc_ctx->sample_fmt = encoder->sample_fmts[0];
-enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
+enc_ctx->time_base = dec_ctx->time_base;
}
if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
--
2.48.1
___
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".
[FFmpeg-devel] [PATCHv3] examples/transcoding: Fix time_base handling
--- Begin Message ---
From bfd5500a5448ad468d32994816e8a55c0d4a2428 Mon Sep 17 00:00:00 2001
From: Jack Lau
Date: Tue, 4 Feb 2025 21:39:20 +0800
Subject: [PATCH] examples/transcoding: Fix time_base handling
X-Unsent: 1
To: ffmpeg-devel@ffmpeg.org
The `dec_ctx->time_base` was incorrectly default set to 0/60, while
`enc_ctx->time_base` was derived from `dec_ctx->framerate`. This mismatch could
cause incorrect video duration in the output.
This patch aligns `enc_ctx->time_base` with `dec_ctx->time_base` to prevent
rescaling issues and ensure correct video duration.
Signed-off-by: JackLau1222 <2366536...@qq.com>
---
doc/examples/transcoding.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 013f89fc7d..847bdb7e1a 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -172,7 +172,7 @@ static int open_output_file(const char *filename)
else
enc_ctx->pix_fmt = dec_ctx->pix_fmt;
/* video time_base can be set to whatever is handy and
supported by encoder */
-enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
+enc_ctx->time_base = dec_ctx->time_base;
} else {
enc_ctx->sample_rate = dec_ctx->sample_rate;
ret = av_channel_layout_copy(&enc_ctx->ch_layout,
&dec_ctx->ch_layout);
@@ -180,7 +180,7 @@ static int open_output_file(const char *filename)
return ret;
/* take first format from list of supported formats */
enc_ctx->sample_fmt = encoder->sample_fmts[0];
-enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
+enc_ctx->time_base = dec_ctx->time_base;
}
if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
--
2.45.2
--- End 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".
[FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
fix-time-base-handling.patch Description: Binary data ___ 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".
Re: [FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
>
> AVCodecContext.time_base is not used for decoding.
Thank you for your reply. I understand that time_base is not used during
decoding, but the transcoding code calls av_packet_rescale_ts twice, once
before decoding and once after encoding, as shown below:
540 if (filter_ctx[stream_index].filter_graph) {
541 StreamContext *stream = &stream_ctx[stream_index];
542
543 av_log(NULL, AV_LOG_DEBUG, "Going to reencode&filter the
frame\n");
544
545 av_packet_rescale_ts(packet,
546 ifmt_ctx->streams[stream_index]->time_base,
547 stream->dec_ctx->time_base);
548 ret = avcodec_send_packet(stream->dec_ctx, packet);
448 /* prepare packet for muxing */
449 enc_pkt->stream_index = stream_index;
450 av_packet_rescale_ts(enc_pkt,
451 stream->enc_ctx->time_base,
452 ofmt_ctx->streams[stream_index]->time_base);
453
454 av_log(NULL, AV_LOG_DEBUG, "Muxing frame\n");
455 /* mux encoded frame */
456 ret = av_interleaved_write_frame(ofmt_ctx, enc_pkt);
If dec_ctx->time_base and enc_ctx->time_base are not consistent, it can lead to
incorrect packet duration, which in turn causes issues with the output file's
duration.
___
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".
Re: [FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
>
> AVCodecContext.time_base is not used for decoding.
Thank you for your reply. I understand that time_base is not used during
decoding, but the transcoding code calls av_packet_rescale_ts twice, once
before decoding and once after encoding, as shown below:
540 if (filter_ctx[stream_index].filter_graph) {
541 StreamContext *stream = &stream_ctx[stream_index];
542
543 av_log(NULL, AV_LOG_DEBUG, "Going to reencode&filter the
frame\n");
544
545 av_packet_rescale_ts(packet,
546 ifmt_ctx->streams[stream_index]->time_base,
547 stream->dec_ctx->time_base);
548 ret = avcodec_send_packet(stream->dec_ctx, packet);
448 /* prepare packet for muxing */
449 enc_pkt->stream_index = stream_index;
450 av_packet_rescale_ts(enc_pkt,
451 stream->enc_ctx->time_base,
452 ofmt_ctx->streams[stream_index]->time_base);
453
454 av_log(NULL, AV_LOG_DEBUG, "Muxing frame\n");
455 /* mux encoded frame */
456 ret = av_interleaved_write_frame(ofmt_ctx, enc_pkt);
If dec_ctx->time_base and enc_ctx->time_base are not consistent, it can lead to
incorrect packet duration, which in turn causes issues with the output file's
duration.
___
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".
[FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
The `dec_ctx->time_base` was incorrectly default set to 0/60, while
`enc_ctx->time_base` was derived from `dec_ctx->framerate`. This mismatch
could cause incorrect video duration in the output.
This patch aligns `enc_ctx->time_base` with `dec_ctx->time_base` to prevent
rescaling issues and ensure correct video duration.
Signed-off-by: Jack Lau
---
doc/examples/transcoding.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 013f89fc7d..847bdb7e1a 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -172,7 +172,7 @@ static int open_output_file(const char *filename)
else
enc_ctx->pix_fmt = dec_ctx->pix_fmt;
/* video time_base can be set to whatever is handy and
supported by encoder */
-enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
+enc_ctx->time_base = dec_ctx->time_base;
} else {
enc_ctx->sample_rate = dec_ctx->sample_rate;
ret = av_channel_layout_copy(&enc_ctx->ch_layout,
&dec_ctx->ch_layout);
@@ -180,7 +180,7 @@ static int open_output_file(const char *filename)
return ret;
/* take first format from list of supported formats */
enc_ctx->sample_fmt = encoder->sample_fmts[0];
-enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
+enc_ctx->time_base = dec_ctx->time_base;
}
if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
--
2.45.2
___
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".
[FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
The `dec_ctx->time_base` was incorrectly default set to 0/60, while
`enc_ctx->time_base` was derived from `dec_ctx->framerate`. This mismatch could
cause incorrect video duration in the output.
This patch aligns `enc_ctx->time_base` with `dec_ctx->time_base` to prevent
rescaling issues and ensure correct video duration.
Signed-off-by: JackLau1222 <2366536...@qq.com>
---
doc/examples/transcoding.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 013f89fc7d..847bdb7e1a 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -172,7 +172,7 @@ static int open_output_file(const char *filename)
else
enc_ctx->pix_fmt = dec_ctx->pix_fmt;
/* video time_base can be set to whatever is handy and supported
by encoder */
-enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
+enc_ctx->time_base = dec_ctx->time_base;
} else {
enc_ctx->sample_rate = dec_ctx->sample_rate;
ret = av_channel_layout_copy(&enc_ctx->ch_layout,
&dec_ctx->ch_layout);
@@ -180,7 +180,7 @@ static int open_output_file(const char *filename)
return ret;
/* take first format from list of supported formats */
enc_ctx->sample_fmt = encoder->sample_fmts[0];
-enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
+enc_ctx->time_base = dec_ctx->time_base;
}
if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
--
2.45.2
___
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".
Re: [FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
To be clear, i want to give an example, i use a 10s duration, 30fps video.
The ifmt_ctx->streams[stream_index]->time_base is same as
ofmt_ctx->streams[stream_index]->time_base after initializing.
The stream->dec_ctx->time_base is default 0,60 but
stream->enc_ctx->time_base is set to av_inv_q(dec_ctx->framerate) so it's
0,30
174 /* video time_base can be set to whatever is handy and
supported by encoder */
175 enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
so the twice rescale is this:
input pkt in_tb: 15360 out_tb: 60
output pkt in_tb: 30 out_tb: 15360
so i get one 20s duration and 15fps video(audio duration is normal because
the input's audio sample ratio is 44100)
So i think the problem is that the enc_ctx->time_base shouldn't set to
av_inv_q(dec_ctx->framerate)
On Wed, Feb 5, 2025 at 10:29 AM Jack Lau wrote:
>
> AVCodecContext.time_base is not used for decoding.
>
>
>
> Thank you for your reply. I understand that time_base is not used during
> decoding, but the transcoding code calls av_packet_rescale_ts twice, once
> before decoding and once after encoding, as shown below:
>
> 540 if (filter_ctx[stream_index].filter_graph) {
> 541 StreamContext *stream = &stream_ctx[stream_index];
> 542
> 543 av_log(NULL, AV_LOG_DEBUG, "Going to reencode&filter the
> frame\n");
> 544
> 545 av_packet_rescale_ts(packet,
>
>
> 546
> ifmt_ctx->streams[stream_index]->time_base,
> 547 stream->dec_ctx->time_base);
> 548 ret = avcodec_send_packet(stream->dec_ctx, packet);
>
> 448 /* prepare packet for muxing */
>
>
> 449 enc_pkt->stream_index = stream_index;
> 450 av_packet_rescale_ts(enc_pkt,
> 451 stream->enc_ctx->time_base,
> 452
> ofmt_ctx->streams[stream_index]->time_base);
> 453
> 454 av_log(NULL, AV_LOG_DEBUG, "Muxing frame\n");
> 455 /* mux encoded frame */
> 456 ret = av_interleaved_write_frame(ofmt_ctx, enc_pkt);
>
> If dec_ctx->time_base and enc_ctx->time_base are not consistent, it can
> lead to incorrect packet duration, which in turn causes issues with the
> output file's duration.
>
___
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".
Re: [FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
Hello.
I found one better method to fix this issue. Firstly, i think the problem
caused by incorrectly setting enc_ctx->time_base, so i refer to the
implementation in avcodec_open2()
361 #if FF_API_AVCTX_TIMEBASE
362if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
363 avctx->time_base = av_inv_q(av_mul_q(avctx->framerate,
(AVRational){avctx->ticks_per_frame, 1}));
364 #endif
this is new version code and i submit it in new mail, it can be reviewed in
https://patchwork.ffmpeg.org/project/ffmpeg/patch/tencent_7adfe69819d49d96fa8bc2c9e688ccec2...@qq.com/
-enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
+enc_ctx->time_base = av_inv_q(av_mul_q(dec_ctx->framerate,
(AVRational){dec_ctx->ticks_per_frame, 1}));
-enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
+enc_ctx->time_base = (AVRational){1, dec_ctx->sample_rate};
but there is new issue in andriy/configure_x86 check:
error: Failed to merge in the changes.
i think it's maybe the mistake of branch? this patch is for release/5.1
branch rather than master branch.
Could any one give me some advice please so that i can fix it?
On Wed, Feb 5, 2025 at 11:25 AM Jack Lau wrote:
> To be clear, i want to give an example, i use a 10s duration, 30fps video.
> The ifmt_ctx->streams[stream_index]->time_base is same as
> ofmt_ctx->streams[stream_index]->time_base after initializing.
> The stream->dec_ctx->time_base is default 0,60 but
> stream->enc_ctx->time_base is set to av_inv_q(dec_ctx->framerate) so it's
> 0,30
>
> 174 /* video time_base can be set to whatever is handy and
> supported by encoder */
> 175 enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
>
> so the twice rescale is this:
> input pkt in_tb: 15360 out_tb: 60
> output pkt in_tb: 30 out_tb: 15360
>
> so i get one 20s duration and 15fps video(audio duration is normal because
> the input's audio sample ratio is 44100)
>
> So i think the problem is that the enc_ctx->time_base shouldn't set to
> av_inv_q(dec_ctx->framerate)
>
> On Wed, Feb 5, 2025 at 10:29 AM Jack Lau wrote:
>
>>
>> AVCodecContext.time_base is not used for decoding.
>>
>>
>>
>> Thank you for your reply. I understand that time_base is not used during
>> decoding, but the transcoding code calls av_packet_rescale_ts twice,
>> once before decoding and once after encoding, as shown below:
>>
>> 540 if (filter_ctx[stream_index].filter_graph) {
>> 541 StreamContext *stream = &stream_ctx[stream_index];
>> 542
>> 543 av_log(NULL, AV_LOG_DEBUG, "Going to reencode&filter the
>> frame\n");
>> 544
>> 545 av_packet_rescale_ts(packet,
>>
>>
>> 546
>> ifmt_ctx->streams[stream_index]->time_base,
>> 547 stream->dec_ctx->time_base);
>> 548 ret = avcodec_send_packet(stream->dec_ctx, packet);
>>
>> 448 /* prepare packet for muxing */
>>
>>
>> 449 enc_pkt->stream_index = stream_index;
>> 450 av_packet_rescale_ts(enc_pkt,
>> 451 stream->enc_ctx->time_base,
>> 452
>> ofmt_ctx->streams[stream_index]->time_base);
>> 453
>> 454 av_log(NULL, AV_LOG_DEBUG, "Muxing frame\n");
>> 455 /* mux encoded frame */
>> 456 ret = av_interleaved_write_frame(ofmt_ctx, enc_pkt);
>>
>> If dec_ctx->time_base and enc_ctx->time_base are not consistent, it can
>> lead to incorrect packet duration, which in turn causes issues with the
>> output file's duration.
>>
>
___
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".
Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment
Hi, Thanks for your reply. I'm trying to fix some issues with hls. I happened to see this typo. Since I saw in the ffmpeg documentation that cosmetic changes should be kept in separate patches, so i submitted it first. Thank you for your advice, I will try my best to submit more important patches. Best wishes Jack > On Feb 10, 2025, at 08:54, Soft Works > wrote: > > > >> -Original Message- >> From: ffmpeg-devel > <mailto:ffmpeg-devel-boun...@ffmpeg.org>> On Behalf Of >> Jack Lau via ffmpeg-devel >> Sent: Monday, February 10, 2025 1:34 AM >> To: ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> >> Cc: Jack Lau mailto:jacklau1...@qq.com>> >> Subject: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an >> extra space in the original comment >> >> --- >> libavformat/hls.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavformat/hls.c b/libavformat/hls.c >> index 3bdc1bc848..c2130bb883 100644 >> --- a/libavformat/hls.c >> +++ b/libavformat/hls.c >> @@ -1993,7 +1993,7 @@ static int hls_read_header(AVFormatContext *s) >> return ret; >> >> /* XXX: Some HLS servers don't like being sent the range header, >> - in this case, need to setting http_seekable = 0 to disable >> + in this case, need to setting http_seekable = 0 to disable >>the range header */ >> av_dict_set_int(&c->avio_opts, "seekable", c->http_seekable, 0); >> >> -- >> 2.48.1 > > Hi Jack, > > you're not working on a proof of concept regarding the vulnerability of the > GA, right? > (just kidding) > > As an idea, you might be able to give that patch a little bit more meaning by > also fixing the grammar. > > Best wishes > sw > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@ffmpeg.org> with > subject "unsubscribe". ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment
> On Feb 10, 2025, at 11:08, Marth64 wrote: > > I don't think its fair to shoot this down, its a simple but valid tidy up > work. > I find typos and such when browsing code distracting and readability > important down the road. > Not everyone's first language is English and grammar correction may > not come instinctively. > > Thank you for the contribution Jack. Unless there is any objection on > grounds of maintaining commit history, I'll adjust the grammar of > "need to setting" -> "we need to set" and push this soon. > ___ > 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 Marth, Thanks very much for your reply. I feel the warmth of the open-source community. I indeed did not notice this grammar issue, and I will be more careful next time. It's hard to express my gratitude in words.🥹 Best regards, Jack ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment
> On Feb 10, 2025, at 09:36, Soft Works > wrote: > > > >> -Original Message- >> From: ffmpeg-devel > <mailto:ffmpeg-devel-boun...@ffmpeg.org>> On Behalf Of >> Jack Lau >> Sent: Monday, February 10, 2025 2:13 AM >> To: FFmpeg development discussions and patches > de...@ffmpeg.org <mailto:de...@ffmpeg.org>> >> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is >> an extra space in the original comment >> >>> On Feb 10, 2025, at 08:54, Soft Works > hotmail@ffmpeg.org <mailto:hotmail@ffmpeg.org>> wrote: >>> >>> >>> >>>> -Original Message- >>>> From: ffmpeg-devel >>> <mailto:ffmpeg-devel-boun...@ffmpeg.org> >> <mailto:ffmpeg-devel-boun...@ffmpeg.org>> On Behalf Of >>>> Jack Lau via ffmpeg-devel >>>> Sent: Monday, February 10, 2025 1:34 AM >>>> To: ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> >>>> <mailto:ffmpeg-devel@ffmpeg.org> >>>> Cc: Jack Lau mailto:jacklau1...@qq.com> >>>> <mailto:jacklau1...@qq.com>> >>>> Subject: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an >>>> extra space in the original comment >>>> >>>> --- >>>> libavformat/hls.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/libavformat/hls.c b/libavformat/hls.c >>>> index 3bdc1bc848..c2130bb883 100644 >>>> --- a/libavformat/hls.c >>>> +++ b/libavformat/hls.c >>>> @@ -1993,7 +1993,7 @@ static int hls_read_header(AVFormatContext >> *s) >>>>return ret; >>>> >>>>/* XXX: Some HLS servers don't like being sent the range >> header, >>>> - in this case, need to setting http_seekable = 0 to >> disable >>>> + in this case, need to setting http_seekable = 0 to disable >>>> the range header */ >>>>av_dict_set_int(&c->avio_opts, "seekable", c->http_seekable, >> 0); >>>> >>>> -- >>>> 2.48.1 >>> >>> Hi Jack, >>> >>> you're not working on a proof of concept regarding the >> vulnerability of the GA, right? >>> (just kidding) >>> >>> As an idea, you might be able to give that patch a little bit more >> meaning by also fixing the grammar. >>> >>> Best wishes >>> sw >>> ___ > > >> >> Hi, >> >> Thanks for your reply. >> >> I'm trying to fix some issues with hls. I happened to see this typo. >> Since I saw in the ffmpeg documentation that cosmetic changes should >> be kept in separate patches, so i submitted it first. >> >> Thank you for your advice, I will try my best to submit more >> important patches. >> >> Best wishes >> Jack > > Hi, > > please do not top-post (ask AI if you don't know what it is). It's a rule > here, probably because in those plaintext messages without formatting it's > hard to follow when some are replying at the top and some at the bottom. > > Cosmetic changes should be in a separate commit but they can be in the same > patchset. > > Personally, I don't think it's unimportant to fix whitespace, spelling and > formatting issues. There's value in everything that improves the code, but > you also need to consider efficiency and think about the time that gets bound > for others dealing with a single-char non-functional change. > If I would make such commit(s), then I would go through a large number of > code files (like all from a lib) looking for similar issues and include all > of them in my patch, so that a reviewer/maintainer sees that I have really > spent effort on it, and they feel that the given value is worth their time. > > Best > sw > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@ffmpeg.org> with > subject "unsubscribe”. Hi, Thank you very much for taking the time to point out my mistakes and for sharing your perspective—I completely agree. I will make sure not to encounter these issues again in the future. Thanks again! Jack ___ 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".
Re: [FFmpeg-devel] Captions SCC
> I have been absent from the list for a few years, so I would appreciate it > if someone could catch me up a bit. I am needing to extract and embed scc > files with 608 captions. I am pleased to see that transcoding without > frame rate changes now preserves 608 intact, and there appear to be > extraction and embed functions but they do seem to have bugs for my files > at 1080p2997. Are there any developers willing to take on a paid project > to fix whatever is the issue? Here are the commands I am working with. > > Embed: > "C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -i > "C:\Users\Captions\AIM-2301_premiereDF.mp4" -i > "C:\Captions\AIM-2301_premiereDF.mp4.scc" -map 0:v -map 0:a -map 1 -c:v > copy -c:a copy -c:s mov_text -metadata:s:s:0 language=eng > "C:\Captions\AIM-2301_premiereDFcopy.mp4" > > Extract: > "C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -f lavfi -i > "movie=\'C:\\Captions\\AIM-2301_premiereDF_ffmpegEmbedscc.mp4\'"[out+subcc] > -map 0:1 -c:s copy "C:\Captions\AIM-2301_premiereDF_ffmpegEmbedscc.scc” > Hi, I’ve reviewed the issue with embedding and extracting 608 SCC captions at 1080p2997 resolution and identified a few areas that might help resolve the character duplication and data spill. Here's a summary of my findings: The current command uses -c:s mov_text, but SCC files may work better with -c:s scc to preserve the format correctly. The current command uses a filtergraph that might not map correctly for SCC extraction. Instead, try simplifying the extraction command: -map 0:s:0 -c:s copy Frame Rate Issues: Ensure the video frame rate and the SCC file frame rate match. You might want to force a specific frame rate (e.g., -r 29.97). Let me know if you have further questions. ___ 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".
Re: [FFmpeg-devel] Captions SCC
> > Hi Jack, > > "paying attention next time"? That's not the right answer. > > Please make sure that there won't be a next time. > > The big evil with LLVMs is not the fact they are making mistakes but the > extreme level of confidence at which they are presenting these mistakes - > like no human would do. > That's why we tend to fall so easily into taking their trash for granted. > > sw > > Hi softworkz, Thanks for your reply and reminder, I’ll ensure there won't be a next time. Jack ___ 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".
Re: [FFmpeg-devel] Captions SCC
> > > Hi Zack, > > that message from "Jack" had confused me for a moment, but on re-reading it > appears to be an AI response. > The content is total nonsense. There is no "SCC" encoder in ffmpeg, and if > there was one, it wouldn't help much because the CC data needs to get into > the video frames - so that it exists as input to the video encoder. > For the same reason, it is also not possible to add CCs at the muxer level. > It always requires video encoding because the data needs to get into the > video stream itself, so there's no way to get data from an SCC file into a > video stream currently. > > The only way in the ffmpeg architecture to get CC data encoded would be at > the filtering level. The Subtitle Filtering patchset that I have submitted a > while ago has a "splitcc" filter which has video as input and a video plus a > subtitle pin/pad at the output side. > What would be needed is a reverse pendant like a "mergecc" filter with video > and subtitles input - plus a CEA-608/708 encoder. > > softworkz > Hi softworkz, Sorry about that, The response is indeed from AI. I thought this question was enough for AI to answer, I will pay attention to it next time. Thank you for pointing it out. Jack ___ 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".
Re: [FFmpeg-devel] Captions SCC
Hi softworkz, Thank you very much for your patient reply and kind suggestions. I am new to the FFmpeg devel mailing list, and English is not my native language, so there is still a lot for me to learn. May I ask a question? How long does it usually take for a patch to be reviewed? A few days ago, I submitted a patch titled "[PATCH] examples/transcoding: Fix time_base handling," but it seems that no one has reviewed it yet. I understand everyone is busy, but I was wondering if there has been any feedback or if there are any concerns regarding the patch. Jack > > Hi Jack, > > thanks for your reply and understanding. I wanted to note that it's not about > wrong answers in general. > An answer from yourself that starts with "I think" or similar is very > welcome, even when it might be wrong. :-) > > sw ___ 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".
[FFmpeg-devel] avoption: make the avoption like seekable more general
Hi everyone, I’m trying to solve this issue https://trac.ffmpeg.org/ticket/11394. This ticket shows that we need use `-seekable` and `-http_seekable` to control the range header if send. Because these options belong to different file(hls.c and http.c) So I try to modify the http_seekable to seekable in hls.c, but I realized the avoption parameter will be released after being used once. In that case, the init_input and read_header functions in avformat_open_input of demux.c used avoption successively, resulting in no seekable parameter in the second part of the http request (it has been used and released by init_input). So the second part of http request still not controled by the seekable option. I think it’s necessary to make the avoption used be more general, it can be more friendly to users, there is no need for users to use two options for the same function. So I have two solutions here: 1. Do not release avoption immediately after use, to ensure that all avoptions have a complete life cycle in avformat_open_input, but this will cause a problem, that is, it is impossible to determine which options are used and which are not used. 2. Add new avoption type like general_avoption which has a longer life cycle than ordinary avoption, so that ordinary avoption can still retain the feature of being detected whether it is used. Anyone feel free to give me some advice, I really want to make some contribution for this issue. Thanks Jack ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS Attribute hard code in hevc EXT-X-STREAM-INF
> On Mar 2, 2025, at 15:47, Jack Lau via ffmpeg-devel
> wrote:
>
> fix ticket: 10786
> parse the SPS from extradata and get profile_compatibility, tier, constraints
> which was been hard code before.
>
> HEVC CODECS Attribute reference to: ISO/IEC14496-15
> Signed-off-by: Jack Lau
> ---
> libavformat/hlsenc.c | 37 ++---
> 1 file changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 6148685f40..be7a78021a 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -379,7 +379,10 @@ static void write_codec_attr(AVStream *st, VariantStream
> *vs)
> } else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> uint8_t *data = st->codecpar->extradata;
> int profile = AV_PROFILE_UNKNOWN;
> +uint32_t profile_compatibility = AV_PROFILE_UNKNOWN;
> +char tier = '0';
> int level = AV_LEVEL_UNKNOWN;
> +char constraints[5] = "0";
>
> if (st->codecpar->profile != AV_PROFILE_UNKNOWN)
> profile = st->codecpar->profile;
> @@ -393,6 +396,8 @@ static void write_codec_attr(AVStream *st, VariantStream
> *vs)
> uint8_t *rbsp_buf;
> int remain_size = 0;
> int rbsp_size = 0;
> +uint32_t profile_compatibility_flags = 0;
> +uint8_t high_nibble = 0;
> /* skip start code + nalu header */
> data += 6;
> /* process by reference General NAL unit syntax */
> @@ -406,8 +411,31 @@ static void write_codec_attr(AVStream *st, VariantStream
> *vs)
> }
> /* skip sps_video_parameter_set_id u(4),
> * sps_max_sub_layers_minus1u(3),
> - * and sps_temporal_id_nesting_flag u(1) */
> + * and sps_temporal_id_nesting_flag u(1)
> + *
> + * TIER represents the general_tier_flag, with 'L'
> indicating the flag is 0,
> + * and 'H' indicating the flag is 1
> + */
> +tier = (int)(rbsp_buf[1] & 0x20) == 0 ? 'L' : 'H';
> profile = rbsp_buf[1] & 0x1f;
> +/* PROFILE_COMPATIBILITY is
> general_profile_compatibility_flags, but in reverse bit order,
> + * in a hexadecimal representation (leading zeroes may be
> omitted).
> + */
> +profile_compatibility_flags = (rbsp_buf[2] << 24) |
> (rbsp_buf[3] << 16) | (rbsp_buf[4] << 8) | rbsp_buf[5];
> +/* revise these bits to get the profile compatibility value
> */
> +for (int i = 0; i < 32; i++) {
> +profile_compatibility = (profile_compatibility << 1) |
> (profile_compatibility_flags & 1);
> +profile_compatibility_flags >>= 1;
> +}
> +/* skip 8 + 8 + 32
> + * CONSTRAINTS is a hexadecimal representation of the
> general_constraint_indicator_flags.
> + * each byte is separated by a '.', and trailing zero bytes
> may be omitted.
> + * drop the trailing zero bytes refer to ISO/IEC14496-15.
> + */
> +high_nibble = rbsp_buf[7] >> 4;
> +snprintf(constraints, sizeof(constraints),
> + high_nibble ? "%02x.%x" : "%02x",
> + rbsp_buf[6], high_nibble);
> /* skip 8 + 8 + 32 + 4 + 43 + 1 bit */
> level = rbsp_buf[12];
> av_freep(&rbsp_buf);
> @@ -417,8 +445,11 @@ static void write_codec_attr(AVStream *st, VariantStream
> *vs)
> }
> if (st->codecpar->codec_tag == MKTAG('h','v','c','1') &&
> profile != AV_PROFILE_UNKNOWN &&
> -level != AV_LEVEL_UNKNOWN) {
> -snprintf(attr, sizeof(attr), "%s.%d.4.L%d.B01",
> av_fourcc2str(st->codecpar->codec_tag), profile, level);
> +profile_compatibility != AV_PROFILE_UNKNOWN &&
> +tier != '0' &&
> +level != AV_LEVEL_UNKNOWN &&
> +strcmp(constraints, "0") != 0) {
> +snprintf(attr, sizeof(attr), "%s.%d.%x.%c%d.%s",
> av_fourcc2str(st->codecpar->codec_tag), profile, profile_compatibility, tier,
> level, constraints);
> } else
>
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS Attribute hard code in hevc EXT-X-STREAM-INF
> On Mar 3, 2025, at 09:08, Steven Liu wrote:
>
> Jack Lau via ffmpeg-devel <mailto:ffmpeg-devel@ffmpeg.org>> 于2025年3月2日周日 21:31写道：
>>
>> fix ticket: 10786
>> parse the SPS from extradata and get profile_compatibility, tier,
>> constraints which was been hard code before.
>>
>> HEVC CODECS Attribute reference to: ISO/IEC14496-15
>> Signed-off-by: Jack Lau
>> ---
>> libavformat/hlsenc.c | 41 ++---
>> 1 file changed, 38 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 6148685f40..849130196f 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -379,7 +379,10 @@ static void write_codec_attr(AVStream *st,
>> VariantStream *vs)
>> } else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
>> uint8_t *data = st->codecpar->extradata;
>> int profile = AV_PROFILE_UNKNOWN;
>> +uint32_t profile_compatibility = AV_PROFILE_UNKNOWN;
>> +char tier = 0;
>> int level = AV_LEVEL_UNKNOWN;
>> +char constraints[8] = "";
>>
>> if (st->codecpar->profile != AV_PROFILE_UNKNOWN)
>> profile = st->codecpar->profile;
>> @@ -393,6 +396,8 @@ static void write_codec_attr(AVStream *st, VariantStream
>> *vs)
>> uint8_t *rbsp_buf;
>> int remain_size = 0;
>> int rbsp_size = 0;
>> +uint32_t profile_compatibility_flags = 0;
>> +uint8_t high_nibble = 0;
>> /* skip start code + nalu header */
>> data += 6;
>> /* process by reference General NAL unit syntax */
>> @@ -406,8 +411,35 @@ static void write_codec_attr(AVStream *st,
>> VariantStream *vs)
>> }
>> /* skip sps_video_parameter_set_id u(4),
>> * sps_max_sub_layers_minus1u(3),
>> - * and sps_temporal_id_nesting_flag u(1) */
>> + * and sps_temporal_id_nesting_flag u(1)
>> + *
>> + * TIER represents the general_tier_flag, with 'L'
>> indicating the flag is 0,
>> + * and 'H' indicating the flag is 1
>> + */
>> +tier = (int)(rbsp_buf[1] & 0x20) == 0 ? 'L' : 'H';
> Since 'tier' is a char, the cast to (int) should be unnecessary.
Got it! remove (int) already in the latest patch.
>> profile = rbsp_buf[1] & 0x1f;
>> +/* PROFILE_COMPATIBILITY is
>> general_profile_compatibility_flags, but in reverse bit order,
>> + * in a hexadecimal representation (leading zeroes may be
>> omitted).
>> + */
>> +profile_compatibility_flags = AV_RB32(rbsp_buf + 2);
>> +/* revise these bits to get the profile compatibility value
>> */
>> +{
> remove this braces
>
>> + uint32_t x = profile_compatibility_flags;
>> +x = ((x & 0xU) << 1) | ((x >> 1) & 0xU);
>> +x = ((x & 0xU) << 2) | ((x >> 2) & 0xU);
>> +x = ((x & 0x0F0F0F0FU) << 4) | ((x >> 4) & 0x0F0F0F0FU);
>> +x = ((x & 0x00FF00FFU) << 8) | ((x >> 8) & 0x00FF00FFU);
>> +profile_compatibility = (x << 16) | (x >> 16);
>> +}
> ditoo
Thank you for reminding me of this problem. In the latest patch, I not only
removed braces, but also removed the temporary variable x. Direct bit
operations on profile_compatibility_flags will save more resources.
>> +/* skip 8 + 8 + 32
>> + * CONSTRAINTS is a hexadecimal representation of the
>> general_constraint_indicator_flags.
>> + * each byte is separated by a '.', and trailing zero bytes
>> may be omitted.
>> + * drop the trailing zero bytes refer to ISO/IEC14496-15.
>> + */
>> +high_nibble = rbsp_buf[7] >> 4;
>> +snprintf(constraints, sizeof(constraints),
>> + high_nibble ? "%02x.%x" : "%02x",
>> + rbsp_buf[6], high_nibble);
>> /* skip 8 + 8 + 32 + 4 + 43 + 1 bit */
>>
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: calculate bitrate for segments with duration < 0.5
> On Mar 24, 2025, at 08:11, Steven Liu wrote:
>
> Jack Lau via ffmpeg-devel <mailto:ffmpeg-devel@ffmpeg.org>> 于2025年3月24日周一 07:13写道：
>>
>> The previous code sets the bitrate to be calculated only when duration>0.5,
>> which is obviously not general enough.
>>
>> In some scenarios, we may need to set hls_time<0.5, then the generated
>> segments are all <0.5. At this time, because the bitrate is not calculated,
>> max_bitrate is empty, and ff_hls_write_stream_info cannot write stream info
>> normally, causing master_pl to be unavailable.
>>
>> Signed-off-by: Jack Lau
>> ---
>> libavformat/hlsenc.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index c6ffdb99e5..223c516103 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1150,9 +1150,7 @@ static int hls_append_segment(struct AVFormatContext
>> *s, HLSContext *hls,
>>
>> vs->total_size += size;
>> vs->total_duration += duration;
>> -if (duration > 0.5) {
>> -// Don't include the final, possibly very short segment in the
>> -// calculation of the max bitrate.
>> +if (duration > 0) {
>
> I'm not sure if this will work well in llhls mode,
> but when the network conditions are even slightly poor,
> severe stuttering or even an inability to continue playback occurs.
> This is because the segments are so small that the network overhead
> exceeds the time it takes to play them.
Thanks for your reply, It seems that the actual situation requires more complex
considerations. I will study it further.
>
>> int cur_bitrate = (int)(8 * size / duration);
>> if (cur_bitrate > vs->max_bitrate)
>> vs->max_bitrate = cur_bitrate;
>> --
>> 2.47.1
>>
>> ___
>> 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".
>
> Thanks
> Steven
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@ffmpeg.org> with
> subject "unsubscribe”.
Regards
Jack
___
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".
Re: [FFmpeg-devel] [PATCH] avformat/dashenc: add hevc codec attributes parse
> On Mar 12, 2025, at 15:06, Jack Lau via ffmpeg-devel
> wrote:
>
> fix ticket: 11316
> add set_hevc_codec_str function refer to hlsenc.c but do some necessary
> changes
> Signed-off-by: Jack Lau
> ---
> libavformat/dashenc.c | 81 +++
> 1 file changed, 81 insertions(+)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index d4a6fe0304..04c5b562d5 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -57,6 +57,7 @@
> #include "url.h"
> #include "vpcc.h"
> #include "dash.h"
> +#include "nal.h"
>
> typedef enum {
>SEGMENT_TYPE_AUTO = 0,
> @@ -344,6 +345,84 @@ static void set_vp9_codec_str(AVFormatContext *s,
> AVCodecParameters *par,
>return;
> }
>
> +static void set_hevc_codec_str(AVCodecParameters *par, char *str, int size) {
> +uint8_t *data = par->extradata;
> +int profile = AV_PROFILE_UNKNOWN;
> +uint32_t profile_compatibility = AV_PROFILE_UNKNOWN;
> +char tier = 0;
> +int level = AV_LEVEL_UNKNOWN;
> +char constraints[8] = "";
> +
> +if (par->profile != AV_PROFILE_UNKNOWN)
> +profile = par->profile;
> +if (par->level != AV_LEVEL_UNKNOWN)
> +level = par->level;
> +
> +/* check the boundary of data which from current position is small than
> extradata_size */
> +while (data && (data - par->extradata + 19) < par->extradata_size) {
> +/* get HEVC SPS NAL and seek to profile_tier_level */
> +if (!(data[0] | data[1] | data[2]) && data[3] == 1 && ((data[4] &
> 0x7E) == 0x42)) {
> +uint8_t *rbsp_buf;
> +int remain_size = 0;
> +int rbsp_size = 0;
> +uint32_t profile_compatibility_flags = 0;
> +uint8_t high_nibble = 0;
> +/* skip start code + nalu header */
> +data += 6;
> +/* process by reference General NAL unit syntax */
> +remain_size = par->extradata_size - (data - par->extradata);
> +rbsp_buf = ff_nal_unit_extract_rbsp(data, remain_size,
> &rbsp_size, 0);
> +if (!rbsp_buf)
> +return;
> +if (rbsp_size < 13) {
> +av_freep(&rbsp_buf);
> +break;
> +}
> +/* skip sps_video_parameter_set_id u(4),
> +* sps_max_sub_layers_minus1u(3),
> +* and sps_temporal_id_nesting_flag u(1)
> +*
> +* TIER represents the general_tier_flag, with 'L' indicating the
> flag is 0,
> +* and 'H' indicating the flag is 1
> +*/
> +tier = (rbsp_buf[1] & 0x20) == 0 ? 'L' : 'H';
> +profile = rbsp_buf[1] & 0x1f;
> +/* PROFILE_COMPATIBILITY is general_profile_compatibility_flags,
> but in reverse bit order,
> +* in a hexadecimal representation (leading zeroes may be
> omitted).
> +*/
> +profile_compatibility_flags = AV_RB32(rbsp_buf + 2);
> +/* revise these bits to get the profile compatibility value */
> +profile_compatibility_flags = ((profile_compatibility_flags &
> 0xU) << 1) | ((profile_compatibility_flags >> 1) & 0xU);
> +profile_compatibility_flags = ((profile_compatibility_flags &
> 0xU) << 2) | ((profile_compatibility_flags >> 2) & 0xU);
> +profile_compatibility_flags = ((profile_compatibility_flags &
> 0x0F0F0F0FU) << 4) | ((profile_compatibility_flags >> 4) & 0x0F0F0F0FU);
> +profile_compatibility_flags = ((profile_compatibility_flags &
> 0x00FF00FFU) << 8) | ((profile_compatibility_flags >> 8) & 0x00FF00FFU);
> +profile_compatibility = (profile_compatibility_flags << 16) |
> (profile_compatibility_flags >> 16);
> +/* skip 8 + 8 + 32
> +* CONSTRAINTS is a hexadecimal representation of the
> general_constraint_indicator_flags.
> +* each byte is separated by a '.', and trailing zero bytes may
> be omitted.
> +* drop the trailing zero bytes refer to ISO/IEC14496-15.
> +*/
> +high_nibble = rbsp_buf[7] >> 4;
> +snprintf(constraints, sizeof(constraints),
> +high_nibble ? "%02x.%x" : "%02x",
> +rbsp_buf[6], high_nibble);
> +/* skip 8 + 8 + 32 + 4 + 43 +
[FFmpeg-devel] WHIP Feature latest patch Preparation Notes
Hi everyone,
I’m excited to be a GSoC student this year, working on supporting the WHIP
feature in FFmpeg with my mentors Steven Liu and Zhao Jun.
Two years ago, my mentor Steven Liu sent a whip
patch(https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230529115039.17409-1...@chinaffmpeg.org/)
and got some reviews, most of these reviews were fixed except DTLS. So I
refactored the DTLS implementation and merged it into tls_openssl.c.
Before I send out the latest patch, I plan to respond to the previous reviews
one by one. BTW, most of response from Winlin
(https://github.com/ossrs/ffmpeg-webrtc/discussions)
On Mon May 29 16:00:33 EEST 2023, Michael Niedermayer wrote:
>
> On Mon, May 29, 2023 at 07:50:39PM +0800, Steven Liu wrote:
> > Co-authored-by: winlin
> > Co-authored-by: yangrtc
> > Co-authored-by: cloudwebrtc
> > Co-authored-by: Haibo Chen <495810242 at qq.com>
> > Signed-off-by: Steven Liu
> > ---
> > configure | 1 +
> > doc/muxers.texi | 50 +
> > libavformat/Makefile | 1 +
> > libavformat/allformats.c | 1 +
> > libavformat/http.c | 6 +
> > libavformat/http.h | 2 +
> > libavformat/rtcenc.c | 2208 ++
> > 7 files changed, 2269 insertions(+)
> > create mode 100644 libavformat/rtcenc.c
>
> breaks build:
>
> CC libavformat/rtcenc.o
> libavformat/rtcenc.c:30:2: error: #error "OpenSSL version 1.1.1b or newer is
> required"
> #error "OpenSSL version 1.1.1b or newer is required"
> ^
> libavformat/rtcenc.c: In function ‘dtls_context_init’:
> libavformat/rtcenc.c:210:34: error: implicit declaration of function
> ‘EVP_EC_gen’; did you mean ‘EVP_PBE_get’?
> [-Werror=implicit-function-declaration]
> ctx->dtls_pkey = dtls_pkey = EVP_EC_gen(curve);
> ^~
> EVP_PBE_get
Winlin: This issue was caused by a combination of OpenSSL version check and API
usage. I tested a set of OpenSSL versions, fixed the issue, and found that
OpenSSL 1.0.1k and newer versions should work now.
OpenSSL 1.0.1k or newer versions are supported.
Fixed.
> libavformat/rtcenc.c:210:32: warning: assignment makes pointer from integer
> without a cast [-Wint-conversion]
> ctx->dtls_pkey = dtls_pkey = EVP_EC_gen(curve);
> ^
> cc1: some warnings being treated as errors
> ffbuild/common.mak:81: recipe for target 'libavformat/rtcenc.o' failed
> make: *** [libavformat/rtcenc.o] Error 1
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
On Tue May 30 11:44:06 EEST 2023, Kieran Kunhya wrote:
> On Mon, 29 May 2023 at 12:51, Steven Liu wrote:
>
> > Co-authored-by: winlin
> > Co-authored-by: yangrtc
> > Co-authored-by: cloudwebrtc
> > Co-authored-by: Haibo Chen <495810242 at qq.com>
> > Signed-off-by: Steven Liu
> > ---
> > configure | 1 +
> > doc/muxers.texi | 50 +
> > libavformat/Makefile | 1 +
> > libavformat/allformats.c | 1 +
> > libavformat/http.c | 6 +
> > libavformat/http.h | 2 +
> > libavformat/rtcenc.c | 2208 ++
> > 7 files changed, 2269 insertions(+)
> > create mode 100644 libavformat/rtcenc.c
> >
> > diff --git a/configure b/configure
> > index 495493aa0e..526ddc0bd6 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3483,6 +3483,7 @@ ogg_demuxer_select="dirac_parse"
> > ogv_muxer_select="ogg_muxer"
> > opus_muxer_select="ogg_muxer"
> > psp_muxer_select="mov_muxer"
> > +rtc_muxer_deps_any="openssl"
> > rtp_demuxer_select="sdp_demuxer"
> > rtp_mpegts_muxer_select="mpegts_muxer rtp_muxer"
> > rtpdec_select="asf_demuxer mov_demuxer mpegts_demuxer rm_demuxer
> > rtp_protocol srtp"
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index 31fca17dd6..00052f51b4 100644
> > --- a/doc/muxers.texi
> > +++ b/doc/muxers.texi
> > @@ -1333,6 +1333,56 @@ Set custom HTTP headers, can override built in
> > default headers. Applicable only
> >
> > @end table
> >
> > + at anchor{rtc}
> > + at section rtc
> > +
> > +WebRTC (Real-Time Communication) muxer that supports sub-second latency
> > streaming according to
> > +the WHIP (WebRTC-HTTP ingestion protocol) specification.
> > +
> > +It uses HTTP as a signaling protocol to exchange SDP capabilities and ICE
> > lite candidates. Then,
> > +it uses STUN binding requests and responses to establish a session over
> > UDP. Subsequently, it
> > +initiates a DTLS handshake to exchange the SRTP encryption keys. Lastly,
> > it splits video and
> > +audio frames into RTP packets and encrypts them using SRTP.
> > +
> > +Ensure that you use H.264 without B frames and Opus for the audio codec.
> > For example, to convert
> > +an input file with @command{ffmpeg} to WebRTC:
> > + at example
> > +ffmpeg -re -i input.mp4 -acodec libopus -ar 48000 -ac 2 \
> > + -vcodec libx264 -profile:v baseline -tune zerolatency -threads 1 -bf 0 \
> > + -f rtc "http://localhost:1985/rtc/v1/whip/?app=live&stream=livestream";
> > + at end example
> > +
> > +For this example, we have employed low latency options, resulting in an
> > end-to-end latency of
> > +approximately 150ms.
> > +
> > + at
[FFmpeg-devel] [PATCH v2] examples/transcoding: Fix time_base handling
The `dec_ctx->time_base` was incorrectly default set by avcodec_open2(), while
`enc_ctx->time_base` was derived from `dec_ctx->framerate`. This mismatch could
cause incorrect video duration in the output.
This patch corrects the issue by adjusting the `enc_ctx->time_base` calculation
to account for `ticks_per_frame`, ensuring that the time base is consistent
between the decoder and encoder contexts.
--- Begin Message ---
From 6a02fbaf6c6068040640ff105ad70115fb81b5d2 Mon Sep 17 00:00:00 2001
From: Jack Lau
Date: Tue, 4 Feb 2025 21:39:20 +0800
Subject: [PATCH] examples/transcoding: Fix time_base handling
X-Unsent: 1
To: ffmpeg-devel@ffmpeg.org
The `dec_ctx->time_base` was incorrectly default set by avcodec_open2(), while
`enc_ctx->time_base` was derived from `dec_ctx->framerate`. This mismatch could
cause incorrect video duration in the output.
This patch corrects the issue by adjusting the `enc_ctx->time_base` calculation
to account for `ticks_per_frame`, ensuring that the time base is consistent
between the decoder and encoder contexts.
Signed-off-by: Jack Lau
---
doc/examples/transcoding.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 013f89fc7d..8cc1991267 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -172,7 +172,7 @@ static int open_output_file(const char *filename)
else
enc_ctx->pix_fmt = dec_ctx->pix_fmt;
/* video time_base can be set to whatever is handy and
supported by encoder */
-enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
+enc_ctx->time_base = av_inv_q(av_mul_q(dec_ctx->framerate,
(AVRational){dec_ctx->ticks_per_frame, 1}));
} else {
enc_ctx->sample_rate = dec_ctx->sample_rate;
ret = av_channel_layout_copy(&enc_ctx->ch_layout,
&dec_ctx->ch_layout);
@@ -180,7 +180,7 @@ static int open_output_file(const char *filename)
return ret;
/* take first format from list of supported formats */
enc_ctx->sample_fmt = encoder->sample_fmts[0];
-enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
+enc_ctx->time_base = (AVRational){1,dec_ctx->sample_rate};
}
if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
--
2.48.1
--- End 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".
[FFmpeg-devel] [PATCH] examples/transcoding: Fix time_base handling
From: Jack Lau
The `dec_ctx->time_base` was incorrectly default set by avcodec_open2(), while
`enc_ctx->time_base` was derived from `dec_ctx->framerate`. This mismatch could
cause incorrect video duration in the output.
This patch corrects the issue by adjusting the `enc_ctx->time_base` calculation
to account for `ticks_per_frame`, ensuring that the time base is consistent
between the decoder and encoder contexts.
---
doc/examples/transcoding.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 013f89fc7d..09c2ad4b62 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -172,7 +172,7 @@ static int open_output_file(const char *filename)
else
enc_ctx->pix_fmt = dec_ctx->pix_fmt;
/* video time_base can be set to whatever is handy and
supported by encoder */
-enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
+enc_ctx->time_base = av_inv_q(av_mul_q(dec_ctx->framerate,
(AVRational){dec_ctx->ticks_per_frame, 1}));
} else {
enc_ctx->sample_rate = dec_ctx->sample_rate;
ret = av_channel_layout_copy(&enc_ctx->ch_layout,
&dec_ctx->ch_layout);
@@ -180,7 +180,7 @@ static int open_output_file(const char *filename)
return ret;
/* take first format from list of supported formats */
enc_ctx->sample_fmt = encoder->sample_fmts[0];
-enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
+enc_ctx->time_base = (AVRational){1, dec_ctx->sample_rate};
}
if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
--
2.48.1
___
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".
[FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment
--- libavformat/hls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/hls.c b/libavformat/hls.c index 3bdc1bc848..c2130bb883 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -1993,7 +1993,7 @@ static int hls_read_header(AVFormatContext *s) return ret; /* XXX: Some HLS servers don't like being sent the range header, - in this case, need to setting http_seekable = 0 to disable + in this case, need to setting http_seekable = 0 to disable the range header */ av_dict_set_int(&c->avio_opts, "seekable", c->http_seekable, 0); -- 2.48.1 ___ 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".
[FFmpeg-devel] [PATCH] avformat/mpegenc: increase the default size of the VBV buffer
Increase the default buffer size to match more modern encoding scenarios.
---
libavformat/mpegenc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 6b6763c30f..2b3b98b894 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -446,11 +446,10 @@ static av_cold int mpeg_mux_init(AVFormatContext *ctx)
stream->max_buffer_size = 6 * 1024 + props->buffer_size / 8;
else {
av_log(ctx, AV_LOG_WARNING,
- "VBV buffer size not set, using default size of 230KB\n"
+ "VBV buffer size not set, using default size of
2048KB\n"
"If you want the mpeg file to be compliant to some
specification\n"
"Like DVD, VCD or others, make sure you set the correct
buffer size\n");
-// FIXME: this is probably too small as default
-stream->max_buffer_size = 230 * 1024;
+stream->max_buffer_size = 2048 * 1024;
}
if (stream->max_buffer_size > 1024 * 8191) {
av_log(ctx, AV_LOG_WARNING, "buffer size %d, too large\n",
stream->max_buffer_size);
--
2.48.1
___
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".
[FFmpeg-devel] [PATCH] avformat/hlsenc: calculate bitrate for segments with duration < 0.5
The previous code sets the bitrate to be calculated only when duration>0.5,
which is obviously not general enough.
In some scenarios, we may need to set hls_time<0.5, then the generated segments
are all <0.5. At this time, because the bitrate is not calculated, max_bitrate
is empty, and ff_hls_write_stream_info cannot write stream info normally,
causing master_pl to be unavailable.
Signed-off-by: Jack Lau
---
libavformat/hlsenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c6ffdb99e5..223c516103 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1150,9 +1150,7 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls,
vs->total_size += size;
vs->total_duration += duration;
-if (duration > 0.5) {
-// Don't include the final, possibly very short segment in the
-// calculation of the max bitrate.
+if (duration > 0) {
int cur_bitrate = (int)(8 * size / duration);
if (cur_bitrate > vs->max_bitrate)
vs->max_bitrate = cur_bitrate;
--
2.47.1
___
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".
[FFmpeg-devel] [PATCH] avformat/dashdec: just make seg->url in absolute path once
Should fix ticket 11543 if input url is relative path, the seg-url would make absolute url twice in get_content_url and open_input function but it doesn't need make absolute url in open_input since we set it already Signed-off-by: Jack Lau --- libavformat/dashdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c index c3f3d7f3f8..2915f6eb82 100644 --- a/libavformat/dashdec.c +++ b/libavformat/dashdec.c @@ -1700,7 +1700,7 @@ static int open_input(DASHContext *c, struct representation *pls, struct fragmen av_dict_set_int(&opts, "end_offset", seg->url_offset + seg->size, 0); } -ff_make_absolute_url(url, c->max_url_size, c->base_url, seg->url); +ff_make_absolute_url(url, c->max_url_size, "", seg->url); av_log(pls->parent, AV_LOG_VERBOSE, "DASH request for url '%s', offset %"PRId64"\n", url, seg->url_offset); ret = open_url(pls->parent, &pls->input, url, &c->avio_opts, opts, NULL); -- 2.49.0 ___ 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".
[FFmpeg-devel] [PATCH] avformat/rtpdec_mpeg4: add need_parsing for rtsp AAC
fix ticket #11531
the rtsp aac did not marked keyframe which cannot easy copy to output.
because f265f9c9d04863180503707bfad285f48e6bf080 commit change the AAC props to
match xHE-AAC.
in some formats like MOV, need_parsing is set, so AAC can be still parsed be
keyframe
but rtsp did not, so this patch add it
Signed-off-by: Jack Lau
---
libavformat/rtpdec_mpeg4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
index 6531632b2d..c506bcbed1 100644
--- a/libavformat/rtpdec_mpeg4.c
+++ b/libavformat/rtpdec_mpeg4.c
@@ -363,6 +363,7 @@ const RTPDynamicProtocolHandler
ff_mpeg4_generic_dynamic_handler = {
.enc_name = "mpeg4-generic",
.codec_type = AVMEDIA_TYPE_AUDIO,
.codec_id = AV_CODEC_ID_AAC,
+.need_parsing = AVSTREAM_PARSE_HEADERS,
.priv_data_size = sizeof(PayloadContext),
.parse_sdp_a_line = parse_sdp_line,
.close = close_context,
--
2.49.0
___
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".
[FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS Attribute hard code in hevc EXT-X-STREAM-INF
fix ticket: 10786
parse the SPS from extradata and get profile_compatibility, tier, constraints
which was been hard code before.
HEVC CODECS Attribute reference to: ISO/IEC14496-15
Signed-off-by: Jack Lau
---
libavformat/hlsenc.c | 41 ++---
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 6148685f40..849130196f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -379,7 +379,10 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
uint8_t *data = st->codecpar->extradata;
int profile = AV_PROFILE_UNKNOWN;
+uint32_t profile_compatibility = AV_PROFILE_UNKNOWN;
+char tier = 0;
int level = AV_LEVEL_UNKNOWN;
+char constraints[8] = "";
if (st->codecpar->profile != AV_PROFILE_UNKNOWN)
profile = st->codecpar->profile;
@@ -393,6 +396,8 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
uint8_t *rbsp_buf;
int remain_size = 0;
int rbsp_size = 0;
+uint32_t profile_compatibility_flags = 0;
+uint8_t high_nibble = 0;
/* skip start code + nalu header */
data += 6;
/* process by reference General NAL unit syntax */
@@ -406,8 +411,35 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
}
/* skip sps_video_parameter_set_id u(4),
* sps_max_sub_layers_minus1u(3),
- * and sps_temporal_id_nesting_flag u(1) */
+ * and sps_temporal_id_nesting_flag u(1)
+ *
+ * TIER represents the general_tier_flag, with 'L' indicating
the flag is 0,
+ * and 'H' indicating the flag is 1
+ */
+tier = (int)(rbsp_buf[1] & 0x20) == 0 ? 'L' : 'H';
profile = rbsp_buf[1] & 0x1f;
+/* PROFILE_COMPATIBILITY is
general_profile_compatibility_flags, but in reverse bit order,
+ * in a hexadecimal representation (leading zeroes may be
omitted).
+ */
+profile_compatibility_flags = AV_RB32(rbsp_buf + 2);
+/* revise these bits to get the profile compatibility value */
+{
+ uint32_t x = profile_compatibility_flags;
+x = ((x & 0xU) << 1) | ((x >> 1) & 0xU);
+x = ((x & 0xU) << 2) | ((x >> 2) & 0xU);
+x = ((x & 0x0F0F0F0FU) << 4) | ((x >> 4) & 0x0F0F0F0FU);
+x = ((x & 0x00FF00FFU) << 8) | ((x >> 8) & 0x00FF00FFU);
+profile_compatibility = (x << 16) | (x >> 16);
+}
+/* skip 8 + 8 + 32
+ * CONSTRAINTS is a hexadecimal representation of the
general_constraint_indicator_flags.
+ * each byte is separated by a '.', and trailing zero bytes
may be omitted.
+ * drop the trailing zero bytes refer to ISO/IEC14496-15.
+ */
+high_nibble = rbsp_buf[7] >> 4;
+snprintf(constraints, sizeof(constraints),
+ high_nibble ? "%02x.%x" : "%02x",
+ rbsp_buf[6], high_nibble);
/* skip 8 + 8 + 32 + 4 + 43 + 1 bit */
level = rbsp_buf[12];
av_freep(&rbsp_buf);
@@ -417,8 +449,11 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
}
if (st->codecpar->codec_tag == MKTAG('h','v','c','1') &&
profile != AV_PROFILE_UNKNOWN &&
-level != AV_LEVEL_UNKNOWN) {
-snprintf(attr, sizeof(attr), "%s.%d.4.L%d.B01",
av_fourcc2str(st->codecpar->codec_tag), profile, level);
+profile_compatibility != AV_PROFILE_UNKNOWN &&
+tier != 0 &&
+level != AV_LEVEL_UNKNOWN &&
+constraints[0] != '\0') {
+snprintf(attr, sizeof(attr), "%s.%d.%x.%c%d.%s",
av_fourcc2str(st->codecpar->codec_tag), profile, profile_compatibility, tier,
level, constraints);
} else
goto fail;
} else if (st->codecpar->codec_id == AV_CODEC_ID_MP2) {
--
2.47.1
___
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".
[FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS Attribute hard code in hevc EXT-X-STREAM-INF
fix ticket: 10786
parse the SPS from extradata and get profile_compatibility, tier, constraints
which was been hard code before.
HEVC CODECS Attribute reference to: ISO/IEC14496-15
Signed-off-by: Jack Lau
---
libavformat/hlsenc.c | 38 +++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 6148685f40..c6ffdb99e5 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -379,7 +379,10 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
uint8_t *data = st->codecpar->extradata;
int profile = AV_PROFILE_UNKNOWN;
+uint32_t profile_compatibility = AV_PROFILE_UNKNOWN;
+char tier = 0;
int level = AV_LEVEL_UNKNOWN;
+char constraints[8] = "";
if (st->codecpar->profile != AV_PROFILE_UNKNOWN)
profile = st->codecpar->profile;
@@ -393,6 +396,8 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
uint8_t *rbsp_buf;
int remain_size = 0;
int rbsp_size = 0;
+uint32_t profile_compatibility_flags = 0;
+uint8_t high_nibble = 0;
/* skip start code + nalu header */
data += 6;
/* process by reference General NAL unit syntax */
@@ -406,8 +411,32 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
}
/* skip sps_video_parameter_set_id u(4),
* sps_max_sub_layers_minus1u(3),
- * and sps_temporal_id_nesting_flag u(1) */
+ * and sps_temporal_id_nesting_flag u(1)
+ *
+ * TIER represents the general_tier_flag, with 'L' indicating
the flag is 0,
+ * and 'H' indicating the flag is 1
+ */
+tier = (rbsp_buf[1] & 0x20) == 0 ? 'L' : 'H';
profile = rbsp_buf[1] & 0x1f;
+/* PROFILE_COMPATIBILITY is
general_profile_compatibility_flags, but in reverse bit order,
+ * in a hexadecimal representation (leading zeroes may be
omitted).
+ */
+profile_compatibility_flags = AV_RB32(rbsp_buf + 2);
+/* revise these bits to get the profile compatibility value */
+profile_compatibility_flags = ((profile_compatibility_flags &
0xU) << 1) | ((profile_compatibility_flags >> 1) & 0xU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0xU) << 2) | ((profile_compatibility_flags >> 2) & 0xU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0x0F0F0F0FU) << 4) | ((profile_compatibility_flags >> 4) & 0x0F0F0F0FU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0x00FF00FFU) << 8) | ((profile_compatibility_flags >> 8) & 0x00FF00FFU);
+profile_compatibility = (profile_compatibility_flags << 16) |
(profile_compatibility_flags >> 16);
+/* skip 8 + 8 + 32
+ * CONSTRAINTS is a hexadecimal representation of the
general_constraint_indicator_flags.
+ * each byte is separated by a '.', and trailing zero bytes
may be omitted.
+ * drop the trailing zero bytes refer to ISO/IEC14496-15.
+ */
+high_nibble = rbsp_buf[7] >> 4;
+snprintf(constraints, sizeof(constraints),
+ high_nibble ? "%02x.%x" : "%02x",
+ rbsp_buf[6], high_nibble);
/* skip 8 + 8 + 32 + 4 + 43 + 1 bit */
level = rbsp_buf[12];
av_freep(&rbsp_buf);
@@ -417,8 +446,11 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
}
if (st->codecpar->codec_tag == MKTAG('h','v','c','1') &&
profile != AV_PROFILE_UNKNOWN &&
-level != AV_LEVEL_UNKNOWN) {
-snprintf(attr, sizeof(attr), "%s.%d.4.L%d.B01",
av_fourcc2str(st->codecpar->codec_tag), profile, level);
+profile_compatibility != AV_PROFILE_UNKNOWN &&
+tier != 0 &&
+level != AV_LEVEL_UNKNOWN &&
+constraints[0] != '\0') {
+snprintf(attr, sizeof(attr), "%s.%d.%x.%c%d.%s",
av_fourcc2str(st->codecpar->codec_tag), profile, profile_compatibility, tier,
level, constraints);
} else
goto fail;
} else if (st->codecpar->codec_id == AV_CODEC_ID_MP2) {
--
2.47.1
___
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".
[FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS Attribute hard code in hevc EXT-X-STREAM-INF
fix ticket: 10786
parse the SPS from extradata and get profile_compatibility, tier, constraints
which was been hard code before.
HEVC CODECS Attribute reference to: ISO/IEC14496-15
Signed-off-by: Jack Lau
---
libavformat/hlsenc.c | 37 ++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 6148685f40..be7a78021a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -379,7 +379,10 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
uint8_t *data = st->codecpar->extradata;
int profile = AV_PROFILE_UNKNOWN;
+uint32_t profile_compatibility = AV_PROFILE_UNKNOWN;
+char tier = '0';
int level = AV_LEVEL_UNKNOWN;
+char constraints[5] = "0";
if (st->codecpar->profile != AV_PROFILE_UNKNOWN)
profile = st->codecpar->profile;
@@ -393,6 +396,8 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
uint8_t *rbsp_buf;
int remain_size = 0;
int rbsp_size = 0;
+uint32_t profile_compatibility_flags = 0;
+uint8_t high_nibble = 0;
/* skip start code + nalu header */
data += 6;
/* process by reference General NAL unit syntax */
@@ -406,8 +411,31 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
}
/* skip sps_video_parameter_set_id u(4),
* sps_max_sub_layers_minus1u(3),
- * and sps_temporal_id_nesting_flag u(1) */
+ * and sps_temporal_id_nesting_flag u(1)
+ *
+ * TIER represents the general_tier_flag, with 'L' indicating
the flag is 0,
+ * and 'H' indicating the flag is 1
+ */
+tier = (int)(rbsp_buf[1] & 0x20) == 0 ? 'L' : 'H';
profile = rbsp_buf[1] & 0x1f;
+/* PROFILE_COMPATIBILITY is
general_profile_compatibility_flags, but in reverse bit order,
+ * in a hexadecimal representation (leading zeroes may be
omitted).
+ */
+profile_compatibility_flags = (rbsp_buf[2] << 24) |
(rbsp_buf[3] << 16) | (rbsp_buf[4] << 8) | rbsp_buf[5];
+/* revise these bits to get the profile compatibility value */
+for (int i = 0; i < 32; i++) {
+profile_compatibility = (profile_compatibility << 1) |
(profile_compatibility_flags & 1);
+profile_compatibility_flags >>= 1;
+}
+/* skip 8 + 8 + 32
+ * CONSTRAINTS is a hexadecimal representation of the
general_constraint_indicator_flags.
+ * each byte is separated by a '.', and trailing zero bytes
may be omitted.
+ * drop the trailing zero bytes refer to ISO/IEC14496-15.
+ */
+high_nibble = rbsp_buf[7] >> 4;
+snprintf(constraints, sizeof(constraints),
+ high_nibble ? "%02x.%x" : "%02x",
+ rbsp_buf[6], high_nibble);
/* skip 8 + 8 + 32 + 4 + 43 + 1 bit */
level = rbsp_buf[12];
av_freep(&rbsp_buf);
@@ -417,8 +445,11 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
}
if (st->codecpar->codec_tag == MKTAG('h','v','c','1') &&
profile != AV_PROFILE_UNKNOWN &&
-level != AV_LEVEL_UNKNOWN) {
-snprintf(attr, sizeof(attr), "%s.%d.4.L%d.B01",
av_fourcc2str(st->codecpar->codec_tag), profile, level);
+profile_compatibility != AV_PROFILE_UNKNOWN &&
+tier != '0' &&
+level != AV_LEVEL_UNKNOWN &&
+strcmp(constraints, "0") != 0) {
+snprintf(attr, sizeof(attr), "%s.%d.%x.%c%d.%s",
av_fourcc2str(st->codecpar->codec_tag), profile, profile_compatibility, tier,
level, constraints);
} else
goto fail;
} else if (st->codecpar->codec_id == AV_CODEC_ID_MP2) {
--
2.47.1
___
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".
[FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS Attribute hard code in hevc EXT-X-STREAM-INF
fix ticket: 10786
parse the SPS from extradata and get profile_compatibility, tier, constraints
which was been hard code before.
HEVC CODECS Attribute reference to: ISO/IEC14496-15
Signed-off-by: Jack Lau
---
libavformat/hlsenc.c | 38 +++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 6148685f40..c6ffdb99e5 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -379,7 +379,10 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
} else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
uint8_t *data = st->codecpar->extradata;
int profile = AV_PROFILE_UNKNOWN;
+uint32_t profile_compatibility = AV_PROFILE_UNKNOWN;
+char tier = 0;
int level = AV_LEVEL_UNKNOWN;
+char constraints[8] = "";
if (st->codecpar->profile != AV_PROFILE_UNKNOWN)
profile = st->codecpar->profile;
@@ -393,6 +396,8 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
uint8_t *rbsp_buf;
int remain_size = 0;
int rbsp_size = 0;
+uint32_t profile_compatibility_flags = 0;
+uint8_t high_nibble = 0;
/* skip start code + nalu header */
data += 6;
/* process by reference General NAL unit syntax */
@@ -406,8 +411,32 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
}
/* skip sps_video_parameter_set_id u(4),
* sps_max_sub_layers_minus1u(3),
- * and sps_temporal_id_nesting_flag u(1) */
+ * and sps_temporal_id_nesting_flag u(1)
+ *
+ * TIER represents the general_tier_flag, with 'L' indicating
the flag is 0,
+ * and 'H' indicating the flag is 1
+ */
+tier = (rbsp_buf[1] & 0x20) == 0 ? 'L' : 'H';
profile = rbsp_buf[1] & 0x1f;
+/* PROFILE_COMPATIBILITY is
general_profile_compatibility_flags, but in reverse bit order,
+ * in a hexadecimal representation (leading zeroes may be
omitted).
+ */
+profile_compatibility_flags = AV_RB32(rbsp_buf + 2);
+/* revise these bits to get the profile compatibility value */
+profile_compatibility_flags = ((profile_compatibility_flags &
0xU) << 1) | ((profile_compatibility_flags >> 1) & 0xU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0xU) << 2) | ((profile_compatibility_flags >> 2) & 0xU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0x0F0F0F0FU) << 4) | ((profile_compatibility_flags >> 4) & 0x0F0F0F0FU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0x00FF00FFU) << 8) | ((profile_compatibility_flags >> 8) & 0x00FF00FFU);
+profile_compatibility = (profile_compatibility_flags << 16) |
(profile_compatibility_flags >> 16);
+/* skip 8 + 8 + 32
+ * CONSTRAINTS is a hexadecimal representation of the
general_constraint_indicator_flags.
+ * each byte is separated by a '.', and trailing zero bytes
may be omitted.
+ * drop the trailing zero bytes refer to ISO/IEC14496-15.
+ */
+high_nibble = rbsp_buf[7] >> 4;
+snprintf(constraints, sizeof(constraints),
+ high_nibble ? "%02x.%x" : "%02x",
+ rbsp_buf[6], high_nibble);
/* skip 8 + 8 + 32 + 4 + 43 + 1 bit */
level = rbsp_buf[12];
av_freep(&rbsp_buf);
@@ -417,8 +446,11 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs)
}
if (st->codecpar->codec_tag == MKTAG('h','v','c','1') &&
profile != AV_PROFILE_UNKNOWN &&
-level != AV_LEVEL_UNKNOWN) {
-snprintf(attr, sizeof(attr), "%s.%d.4.L%d.B01",
av_fourcc2str(st->codecpar->codec_tag), profile, level);
+profile_compatibility != AV_PROFILE_UNKNOWN &&
+tier != 0 &&
+level != AV_LEVEL_UNKNOWN &&
+constraints[0] != '\0') {
+snprintf(attr, sizeof(attr), "%s.%d.%x.%c%d.%s",
av_fourcc2str(st->codecpar->codec_tag), profile, profile_compatibility, tier,
level, constraints);
} else
goto fail;
} else if (st->codecpar->codec_id == AV_CODEC_ID_MP2) {
--
2.47.1
___
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".
[FFmpeg-devel] [PATCH] avformat/dashenc: add hevc codec attributes parse
fix ticket: 11316
add set_hevc_codec_str function refer to hlsenc.c but do some necessary changes
Signed-off-by: Jack Lau
---
libavformat/dashenc.c | 81 +++
1 file changed, 81 insertions(+)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index d4a6fe0304..04c5b562d5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -57,6 +57,7 @@
#include "url.h"
#include "vpcc.h"
#include "dash.h"
+#include "nal.h"
typedef enum {
SEGMENT_TYPE_AUTO = 0,
@@ -344,6 +345,84 @@ static void set_vp9_codec_str(AVFormatContext *s,
AVCodecParameters *par,
return;
}
+static void set_hevc_codec_str(AVCodecParameters *par, char *str, int size) {
+uint8_t *data = par->extradata;
+int profile = AV_PROFILE_UNKNOWN;
+uint32_t profile_compatibility = AV_PROFILE_UNKNOWN;
+char tier = 0;
+int level = AV_LEVEL_UNKNOWN;
+char constraints[8] = "";
+
+if (par->profile != AV_PROFILE_UNKNOWN)
+profile = par->profile;
+if (par->level != AV_LEVEL_UNKNOWN)
+level = par->level;
+
+/* check the boundary of data which from current position is small than
extradata_size */
+while (data && (data - par->extradata + 19) < par->extradata_size) {
+/* get HEVC SPS NAL and seek to profile_tier_level */
+if (!(data[0] | data[1] | data[2]) && data[3] == 1 && ((data[4] &
0x7E) == 0x42)) {
+uint8_t *rbsp_buf;
+int remain_size = 0;
+int rbsp_size = 0;
+uint32_t profile_compatibility_flags = 0;
+uint8_t high_nibble = 0;
+/* skip start code + nalu header */
+data += 6;
+/* process by reference General NAL unit syntax */
+remain_size = par->extradata_size - (data - par->extradata);
+rbsp_buf = ff_nal_unit_extract_rbsp(data, remain_size, &rbsp_size,
0);
+if (!rbsp_buf)
+return;
+if (rbsp_size < 13) {
+av_freep(&rbsp_buf);
+break;
+}
+/* skip sps_video_parameter_set_id u(4),
+* sps_max_sub_layers_minus1u(3),
+* and sps_temporal_id_nesting_flag u(1)
+*
+* TIER represents the general_tier_flag, with 'L' indicating the
flag is 0,
+* and 'H' indicating the flag is 1
+*/
+tier = (rbsp_buf[1] & 0x20) == 0 ? 'L' : 'H';
+profile = rbsp_buf[1] & 0x1f;
+/* PROFILE_COMPATIBILITY is general_profile_compatibility_flags,
but in reverse bit order,
+* in a hexadecimal representation (leading zeroes may be omitted).
+*/
+profile_compatibility_flags = AV_RB32(rbsp_buf + 2);
+/* revise these bits to get the profile compatibility value */
+profile_compatibility_flags = ((profile_compatibility_flags &
0xU) << 1) | ((profile_compatibility_flags >> 1) & 0xU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0xU) << 2) | ((profile_compatibility_flags >> 2) & 0xU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0x0F0F0F0FU) << 4) | ((profile_compatibility_flags >> 4) & 0x0F0F0F0FU);
+profile_compatibility_flags = ((profile_compatibility_flags &
0x00FF00FFU) << 8) | ((profile_compatibility_flags >> 8) & 0x00FF00FFU);
+profile_compatibility = (profile_compatibility_flags << 16) |
(profile_compatibility_flags >> 16);
+/* skip 8 + 8 + 32
+* CONSTRAINTS is a hexadecimal representation of the
general_constraint_indicator_flags.
+* each byte is separated by a '.', and trailing zero bytes may be
omitted.
+* drop the trailing zero bytes refer to ISO/IEC14496-15.
+*/
+high_nibble = rbsp_buf[7] >> 4;
+snprintf(constraints, sizeof(constraints),
+high_nibble ? "%02x.%x" : "%02x",
+rbsp_buf[6], high_nibble);
+/* skip 8 + 8 + 32 + 4 + 43 + 1 bit */
+level = rbsp_buf[12];
+av_freep(&rbsp_buf);
+break;
+}
+data++;
+}
+if (profile != AV_PROFILE_UNKNOWN &&
+profile_compatibility != AV_PROFILE_UNKNOWN &&
+tier != 0 &&
+level != AV_LEVEL_UNKNOWN &&
+constraints[0] != '\0') {
+av_strlcatf(str, size, ".%d.%x.%c%d.%s", profile,
profile_compatibility, tier, level, constraints);
+}
+return;
+}
+
static void set_codec_str(AVFormatContext *s, AVCodecParame
