Re: [FFmpeg-devel] [PATCH 1/4] avcodec/proresdec2: change profile only if it is unknown
There seems to be an indentation issue here:
> +if (avctx->profile == FF_PROFILE_UNKNOWN) {
> switch (avctx->codec_tag) {
> case MKTAG('a','p','c','o'):
and here:
> av_log(avctx, AV_LOG_WARNING, "Unknown prores profile %d\n",
> avctx->codec_tag);
> }
> +}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: replace strncpy() with direct assignment
> // Change all the ' --' strings to '~--' so that
> // they can be identified as tokens.
> while ((conflist = strstr(str, " --")) != NULL) {
> -strncpy(conflist, "~--", 3);
> +conflist[0] = '~';
> }
Doesn't this simply replace -- with ~- ?
The comment seems wrong to me...
___
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 11/11] avformat/wavdecuse FFABS to instead of fabs
> FFABS is slower than fabs. Not generally. That is highly dependent on compiler/flags/architecture. In some cases, FFABS may actually be faster, in others maybe not. The expected result would be on-par performance. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffserver: fixed deallocation bug in build_feed_streams
In ffserver.c:build_feed_streams(), the streams pointer is only
correctly reset before deallocation when there is no error.
This may cause ffserver to crash, because stream lives in static
memory, not the heap.
The patch duplicates the behaviour of the non-error case.
>From 00c9203f0349dbae6e701104d5a7f6c4e6fa0159 Mon Sep 17 00:00:00 2001
From: Gregor Riepl
Date: Tue, 24 May 2016 15:17:22 +0200
Subject: [PATCH] ffserver: fixed deallocation bug in build_feed_streams
Signed-off-by: Gregor Riepl
---
ffserver.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ffserver.c b/ffserver.c
index b5bd8f8..1a27583 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -3863,6 +3863,8 @@ drop:
if (avformat_write_header(s, NULL) < 0) {
http_log("Container doesn't support the required parameters\n");
avio_closep(&s->pb);
+s->streams = NULL;
+s->nb_streams = 0;
avformat_free_context(s);
goto bail;
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/dashdec: Differentiate unassigned and zero attributes
This fixes an issue where a timestamp attribute may have a valid zero
value (the UNIX epoch 1970-01-01T00:00:00), but is misinterpreted by
dashdec as being unassigned. This changes the logic that calculates
segment numbers and makes the stream undecodable by dashdec.
The fix originally posted to the issue tracker was incorrect and
changed other parts of the segment calculation logic. With this
patch, only the interpretation of the attributes is changed.
Some warnings are added to account for potential errors in manifests.
Fixes: #8522
Signed-off-by: Gregor Riepl
---
libavformat/dashdec.c | 210 --
1 file changed, 162 insertions(+), 48 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 29d4680c68..f25d1a2bdf 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -20,6 +20,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include
+#include
#include "libavutil/bprint.h"
#include "libavutil/opt.h"
#include "libavutil/time.h"
@@ -129,21 +130,34 @@ typedef struct DASHContext {
struct representation **subtitles;
/* MediaPresentationDescription Attribute */
-uint64_t media_presentation_duration;
-uint64_t suggested_presentation_delay;
-uint64_t availability_start_time;
-uint64_t availability_end_time;
-uint64_t publish_time;
-uint64_t minimum_update_period;
-uint64_t time_shift_buffer_depth;
-uint64_t min_buffer_time;
+uint64_t media_presentation_duration_value;
+uint64_t suggested_presentation_delay_value;
+uint64_t availability_start_time_value;
+uint64_t availability_end_time_value;
+uint64_t publish_time_value;
+uint64_t minimum_update_period_value;
+uint64_t time_shift_buffer_depth_value;
+uint64_t min_buffer_time_value;
/* Period Attribute */
-uint64_t period_duration;
-uint64_t period_start;
+uint64_t period_duration_value;
+uint64_t period_start_value;
/* AdaptationSet Attribute */
-char *adaptionset_lang;
+char *adaptionset_lang_value;
+
+/* Attribute valid flags (true if the attribute exists in the XML
manifest) */
+bool media_presentation_duration_assigned;
+bool suggested_presentation_delay_assigned;
+bool availability_start_time_assigned;
+bool availability_end_time_assigned;
+bool publish_time_assigned;
+bool minimum_update_period_assigned;
+bool time_shift_buffer_depth_assigned;
+bool min_buffer_time_assigned;
+bool period_duration_assigned;
+bool period_start_assigned;
+bool adaptionset_lang_assigned;
int is_live;
AVIOInterruptCB *interrupt_callback;
@@ -867,8 +881,8 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
rep = av_mallocz(sizeof(struct representation));
if (!rep)
return AVERROR(ENOMEM);
-if (c->adaptionset_lang) {
-rep->lang = av_strdup(c->adaptionset_lang);
+if (c->adaptionset_lang_assigned) {
+rep->lang = av_strdup(c->adaptionset_lang_value);
if (!rep->lang) {
av_log(s, AV_LOG_ERROR, "alloc language memory failure\n");
av_freep(&rep);
@@ -1106,7 +1120,10 @@ static int
parse_manifest_adaptationset_attr(AVFormatContext *s, xmlNodePtr adap
av_log(s, AV_LOG_WARNING, "Cannot get AdaptionSet\n");
return AVERROR(EINVAL);
}
-c->adaptionset_lang = xmlGetProp(adaptionset_node, "lang");
+c->adaptionset_lang_value = xmlGetProp(adaptionset_node, "lang");
+if (c->adaptionset_lang_value) {
+c->adaptionset_lang_assigned = true;
+}
return 0;
}
@@ -1162,8 +1179,9 @@ static int parse_manifest_adaptationset(AVFormatContext
*s, const char *url,
}
err:
-xmlFree(c->adaptionset_lang);
-c->adaptionset_lang = NULL;
+xmlFree(c->adaptionset_lang_value);
+c->adaptionset_lang_value = NULL;
+c->adaptionset_lang_assigned = false;
return ret;
}
@@ -1273,29 +1291,37 @@ static int parse_manifest(AVFormatContext *s, const char *url, AVIOContext *in)
val = xmlGetProp(node, attr->name);
if (!av_strcasecmp(attr->name, "availabilityStartTime")) {
-c->availability_start_time = get_utc_date_time_insec(s, val);
-av_log(s, AV_LOG_TRACE, "c->availability_start_time =
[%"PRId64"]\n", c->availability_start_time);
+c->availability_start_time_value = get_utc_date_time_insec(s,
val);
+c->availability_start_time_assigned = true;
+av_log(s, AV_LOG_TRACE, "c->availability_start_time =
[%"PRId64"]\n", c->availability_start_time_value);
} else if (!av_strcasecmp(attr->name, "availabilityEndTime")
Re: [FFmpeg-devel] [PATCH] avformat/dashdec: Differentiate unassigned and zero attributes
+#include Not sure this header can be used every enveriment. Or what about use #define TRUE 1 #define FALSE 0 > ? You are right, this is C99. I'd rather not define a custom boolean type just for this, it would be better if FFmpeg had something like FF_TRUE/FF_FALSE. fftools/ffmpeg_opt.c seems to use int, 0 and 1 for flags. Not very clean, but I can use that if it's ok for you? ___ 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 v2] avformat/dashdec: Differentiate unassigned and zero attributes
This fixes an issue where a timestamp attribute may have a valid zero
value (the UNIX epoch 1970-01-01T00:00:00), but is misinterpreted by
dashdec as being unassigned. This changes the logic that calculates
segment numbers and makes the stream undecodable by dashdec.
The fix originally posted to the issue tracker was incorrect and
changed other parts of the segment calculation logic. With this
patch, only the interpretation of the attributes is changed.
Some warnings are added to account for potential errors in manifests.
v2 change: Use int, 0 and 1 instead of C99 stdbool.
This similar to what's done in fftools/ffmpeg_opt.c.
Fixes: #8522
Signed-off-by: Gregor Riepl
---
libavformat/dashdec.c | 209 --
1 file changed, 161 insertions(+), 48 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 29d4680c68..df5d453c5a 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -129,21 +129,34 @@ typedef struct DASHContext {
struct representation **subtitles;
/* MediaPresentationDescription Attribute */
-uint64_t media_presentation_duration;
-uint64_t suggested_presentation_delay;
-uint64_t availability_start_time;
-uint64_t availability_end_time;
-uint64_t publish_time;
-uint64_t minimum_update_period;
-uint64_t time_shift_buffer_depth;
-uint64_t min_buffer_time;
+uint64_t media_presentation_duration_value;
+uint64_t suggested_presentation_delay_value;
+uint64_t availability_start_time_value;
+uint64_t availability_end_time_value;
+uint64_t publish_time_value;
+uint64_t minimum_update_period_value;
+uint64_t time_shift_buffer_depth_value;
+uint64_t min_buffer_time_value;
/* Period Attribute */
-uint64_t period_duration;
-uint64_t period_start;
+uint64_t period_duration_value;
+uint64_t period_start_value;
/* AdaptationSet Attribute */
-char *adaptionset_lang;
+char *adaptionset_lang_value;
+
+/* Attribute valid flags (true if the attribute exists in the XML
manifest) */
+int media_presentation_duration_assigned;
+int suggested_presentation_delay_assigned;
+int availability_start_time_assigned;
+int availability_end_time_assigned;
+int publish_time_assigned;
+int minimum_update_period_assigned;
+int time_shift_buffer_depth_assigned;
+int min_buffer_time_assigned;
+int period_duration_assigned;
+int period_start_assigned;
+int adaptionset_lang_assigned;
int is_live;
AVIOInterruptCB *interrupt_callback;
@@ -867,8 +880,8 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
rep = av_mallocz(sizeof(struct representation));
if (!rep)
return AVERROR(ENOMEM);
-if (c->adaptionset_lang) {
-rep->lang = av_strdup(c->adaptionset_lang);
+if (c->adaptionset_lang_assigned) {
+rep->lang = av_strdup(c->adaptionset_lang_value);
if (!rep->lang) {
av_log(s, AV_LOG_ERROR, "alloc language memory failure\n");
av_freep(&rep);
@@ -1106,7 +1119,10 @@ static int
parse_manifest_adaptationset_attr(AVFormatContext *s, xmlNodePtr adap
av_log(s, AV_LOG_WARNING, "Cannot get AdaptionSet\n");
return AVERROR(EINVAL);
}
-c->adaptionset_lang = xmlGetProp(adaptionset_node, "lang");
+c->adaptionset_lang_value = xmlGetProp(adaptionset_node, "lang");
+if (c->adaptionset_lang_value) {
+c->adaptionset_lang_assigned = 1;
+}
return 0;
}
@@ -1162,8 +1178,9 @@ static int parse_manifest_adaptationset(AVFormatContext
*s, const char *url,
}
err:
-xmlFree(c->adaptionset_lang);
-c->adaptionset_lang = NULL;
+xmlFree(c->adaptionset_lang_value);
+c->adaptionset_lang_value = NULL;
+c->adaptionset_lang_assigned = 0;
return ret;
}
@@ -1273,29 +1290,37 @@ static int parse_manifest(AVFormatContext *s, const char *url, AVIOContext *in)
val = xmlGetProp(node, attr->name);
if (!av_strcasecmp(attr->name, "availabilityStartTime")) {
-c->availability_start_time = get_utc_date_time_insec(s, val);
-av_log(s, AV_LOG_TRACE, "c->availability_start_time =
[%"PRId64"]\n", c->availability_start_time);
+c->availability_start_time_value = get_utc_date_time_insec(s,
val);
+c->availability_start_time_assigned = 1;
+av_log(s, AV_LOG_TRACE, "c->availability_start_time =
[%"PRId64"]\n", c->availability_start_time_value);
} else if (!av_strcasecmp(attr->name, "availabilityEndTime")) {
-c->availability_end_time = get_utc_date_time_insec(s, val);
-av_log(s, AV_LOG_TRACE, "c->availabi
Re: [FFmpeg-devel] Would a crypto file be acceptable?
The result should be no need to provide "crypto://". The ffmpeg file format detection should detect that ".crypto" should be handled by the crypto plugin. Instead of a custom descriptor file format that is only used for this particular special case, you could also define a custom URI, such as: encrypted-media://key-format:aes128/key:12345667abcdef/iv:12345678/uri:file%3A%2F%2F%2Ftmp%2Ffile.mp4 ___ 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] Would a crypto file be acceptable?
I can't find a single thing about this in the ffmpeg documentation. How is this called, where can I read more about it and - most importantly - does it work out of the box? No, it does not. This was a suggestion that sounds like a better option than a custom metadata descriptor file that is only used for one particular use case, at least to me. Regardless, this would be a rather big security hole as a potential key would be plainly visible in url logging. Therefore "hiding" it in a file is probably a better and more secure approach. The same applies to your custom descriptor file, of course. Especially if it's stored on disk, as ramdisks/pipes/sockets aren't as ubiquitous as you might think. ___ 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] seeking consultancy around FFmpeg
> What we are looking for is pretty straight forward. I like to capture > the HDMI video/audio output of a Chromecast dongle and distribute it > into a LAN network via UDP multicast. Something like this: > > Chromecast -> HDMI -> HDMI-USB Capture -> RPi4/8G (with FFmpeg) -> > UDP/Multicast -> LAN -> TV set > > > UDP Multicast output should use the H.264 hardware encoder comes with > the RPi. This may be helpful for your project: https://blog.danman.eu/new-version-of-lenkeng-hdmi-over-ip-extender-lkv373a/ ___ 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".
