Re: [FFmpeg-devel] [PATCH 2/2] avcodec/tiff: Multi-page support

2019-03-22 Thread Nick Renieris 
Στις Παρ, 22 Μαρ 2019 στις 6:35 μ.μ., ο/η Moritz Barsnick
 έγραψε:
> I was about to write "could you please also update the documentation",
> but just realized that the tiff encoder isn't documented. :-P

Hahah. I can solve that in a later patch :)

Στις Σάβ, 23 Μαρ 2019 στις 12:13 π.μ., ο/η Carl Eugen Hoyos
 έγραψε:
> What is the current behaviour?
> Shouldn't the decoder output all pages as for a video file?

I was told by Paul to do it this way (select based on an option).
I'm assuming it's non-trivial to output all pages given the current
architecture, perhaps Paul can elaborate.
___
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] mpeg12enc: Use all Closed Captions side data

2019-03-22 Thread Mathieu Duponchelle 
It is perfectly valid to have multiple CC Picture User Data
for the same frame. Instead of using the first side_data
potentially present with the A53_CC type, iterate over all
side_data.
---
 libavcodec/mpeg12enc.c | 56 +++---
 1 file changed, 31 insertions(+), 25 deletions(-)

diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index 2bc5289d63..0162939399 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -547,31 +547,37 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, 
int picture_number)
 }
 
 if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
-side_data = av_frame_get_side_data(s->current_picture_ptr->f,
-AV_FRAME_DATA_A53_CC);
-if (side_data) {
-if (side_data->size <= A53_MAX_CC_COUNT * 3 && side_data->size % 3 
== 0) {
-int i = 0;
-
-put_header (s, USER_START_CODE);
-
-put_bits(>pb, 8, 'G');   // user_identifier
-put_bits(>pb, 8, 'A');
-put_bits(>pb, 8, '9');
-put_bits(>pb, 8, '4');
-put_bits(>pb, 8, 3); // 
user_data_type_code
-put_bits(>pb, 8,
-(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); // 
flags, cc_count
-put_bits(>pb, 8, 0xff);  // em_data
-
-for (i = 0; i < side_data->size; i++)
-put_bits(>pb, 8, side_data->data[i]);
-
-put_bits(>pb, 8, 0xff);  // marker_bits
-} else {
-av_log(s->avctx, AV_LOG_WARNING,
-"Warning Closed Caption size (%d) can not exceed 93 bytes "
-"and must be a multiple of 3\n", side_data->size);
+int i;
+
+for (i = 0; i < s->current_picture_ptr->f->nb_side_data; i++) {
+side_data = s->current_picture_ptr->f->side_data[i];
+if (side_data->type != AV_FRAME_DATA_A53_CC)
+  continue;
+
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT * 3 && side_data->size 
% 3 == 0) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(>pb, 8, 'G');   // 
user_identifier
+put_bits(>pb, 8, 'A');
+put_bits(>pb, 8, '9');
+put_bits(>pb, 8, '4');
+put_bits(>pb, 8, 3); // 
user_data_type_code
+put_bits(>pb, 8,
+(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); // 
flags, cc_count
+put_bits(>pb, 8, 0xff);  // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(>pb, 8, side_data->data[i]);
+
+put_bits(>pb, 8, 0xff);  // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size (%d) can not exceed 93 
bytes "
+"and must be a multiple of 3\n", side_data->size);
+}
 }
 }
 }
-- 
2.20.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 v4] avformat/http, icecast, rtsp: Add option to disable send-100-continue

2019-03-22 Thread Jun Li 
The current setting for send-100-continue option is either
enabled if applicable or forced enabled, no option to force
disable the header. This change is to expand the option setting
to provide more flexibility, which is useful for rstp case.
---
 libavformat/http.c| 28 +---
 libavformat/icecast.c |  2 +-
 libavformat/rtsp.c|  1 +
 3 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 74d743850d..5a937994cf 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -113,6 +113,7 @@ typedef struct HTTPContext {
 uint8_t *inflate_buffer;
 #endif /* CONFIG_ZLIB */
 AVDictionary *chained_options;
+/* -1 = try to send if applicable, 0 = always disabled, 1 = always enabled 
*/
 int send_expect_100;
 char *method;
 int reconnect;
@@ -155,7 +156,7 @@ static const AVOption options[] = {
 { "auth_type", "HTTP authentication type", OFFSET(auth_state.auth_type), 
AV_OPT_TYPE_INT, { .i64 = HTTP_AUTH_NONE }, HTTP_AUTH_NONE, HTTP_AUTH_BASIC, D 
| E, "auth_type"},
 { "none", "No auth method set, autodetect", 0, AV_OPT_TYPE_CONST, { .i64 = 
HTTP_AUTH_NONE }, 0, 0, D | E, "auth_type"},
 { "basic", "HTTP basic authentication", 0, AV_OPT_TYPE_CONST, { .i64 = 
HTTP_AUTH_BASIC }, 0, 0, D | E, "auth_type"},
-{ "send_expect_100", "Force sending an Expect: 100-continue header for 
POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
+{ "send_expect_100", "Force sending an Expect: 100-continue header for 
POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, E },
 { "location", "The actual location of the data received", 
OFFSET(location), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
 { "offset", "initial byte offset", OFFSET(off), AV_OPT_TYPE_INT64, { .i64 
= 0 }, 0, INT64_MAX, D },
 { "end_offset", "try to limit the request to bytes preceding this offset", 
OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
@@ -1179,16 +1180,21 @@ static int http_connect(URLContext *h, const char 
*path, const char *local_path,
 local_path, method);
 proxyauthstr = ff_http_auth_create_response(>proxy_auth_state, 
proxyauth,
 local_path, method);
-if (post && !s->post_data) {
-send_expect_100 = s->send_expect_100;
-/* The user has supplied authentication but we don't know the auth 
type,
- * send Expect: 100-continue to get the 401 response including the
- * WWW-Authenticate header, or an 100 continue if no auth actually
- * is needed. */
-if (auth && *auth &&
-s->auth_state.auth_type == HTTP_AUTH_NONE &&
-s->http_code != 401)
-send_expect_100 = 1;
+
+ if (post && !s->post_data) {
+if (s->send_expect_100 != -1) {
+send_expect_100 = s->send_expect_100;
+} else {
+send_expect_100 = 0;
+/* The user has supplied authentication but we don't know the auth 
type,
+ * send Expect: 100-continue to get the 401 response including the
+ * WWW-Authenticate header, or an 100 continue if no auth actually
+ * is needed. */
+if (auth && *auth &&
+s->auth_state.auth_type == HTTP_AUTH_NONE &&
+s->http_code != 401)
+send_expect_100 = 1;
+}
 }
 
 #if FF_API_HTTP_USER_AGENT
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
index c93b06b553..d2198b78ec 100644
--- a/libavformat/icecast.c
+++ b/libavformat/icecast.c
@@ -115,7 +115,7 @@ static int icecast_open(URLContext *h, const char *uri, int 
flags)
 av_dict_set(_dict, "auth_type", "basic", 0);
 av_dict_set(_dict, "headers", headers, 0);
 av_dict_set(_dict, "chunked_post", "0", 0);
-av_dict_set(_dict, "send_expect_100", s->legacy_icecast ? "0" : "1", 
0);
+av_dict_set(_dict, "send_expect_100", s->legacy_icecast ? "-1" : "1", 
0);
 if (NOT_EMPTY(s->content_type))
 av_dict_set(_dict, "content_type", s->content_type, 0);
 else
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ae8811234a..6e67e411b9 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1793,6 +1793,7 @@ redirect:
  sessioncookie);
 av_opt_set(rt->rtsp_hd_out->priv_data, "headers", headers, 0);
 av_opt_set(rt->rtsp_hd_out->priv_data, "chunked_post", "0", 0);
+av_opt_set(rt->rtsp_hd_out->priv_data, "send_expect_100", "0", 0);
 
 /* Initialize the authentication state for the POST session. The HTTP
  * protocol implementation doesn't properly handle multi-pass
-- 
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

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container

2019-03-22 Thread Carl Eugen Hoyos 
2019-03-22 19:29 GMT+01:00, Swaraj Hota :
> I have the meta chunk loaded into a buffer.
> I searched a lot but I couldn't find a way to decompress
> a password protected zip buffer.
>
> I saw zlib is used in the code base, so went through it.
> Found a function "decompress()" but it didn't take a
> password as argument.

Then this currently can't be done.

I will look at your original patch again tomorrow and
likely commit it.

Carl Eugen
___
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 v3] avformat/http, icecast, rtsp: Add option to disable send-100-continue

2019-03-22 Thread Jun Li 
The current setting for send-100-continue option is either
enabled if applicable or forced enabled, no option to force
disable the header. This change is to expand the option setting
to provide more flexibility, which is useful for rstp case.
---
 libavformat/http.c| 8 ++--
 libavformat/icecast.c | 2 +-
 libavformat/rtsp.c| 1 +
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 74d743850d..2911ca29c1 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -113,6 +113,7 @@ typedef struct HTTPContext {
 uint8_t *inflate_buffer;
 #endif /* CONFIG_ZLIB */
 AVDictionary *chained_options;
+/* -1 = try to send if applicable, 0 = always disabled, 1 = always enabled 
*/
 int send_expect_100;
 char *method;
 int reconnect;
@@ -155,7 +156,7 @@ static const AVOption options[] = {
 { "auth_type", "HTTP authentication type", OFFSET(auth_state.auth_type), 
AV_OPT_TYPE_INT, { .i64 = HTTP_AUTH_NONE }, HTTP_AUTH_NONE, HTTP_AUTH_BASIC, D 
| E, "auth_type"},
 { "none", "No auth method set, autodetect", 0, AV_OPT_TYPE_CONST, { .i64 = 
HTTP_AUTH_NONE }, 0, 0, D | E, "auth_type"},
 { "basic", "HTTP basic authentication", 0, AV_OPT_TYPE_CONST, { .i64 = 
HTTP_AUTH_BASIC }, 0, 0, D | E, "auth_type"},
-{ "send_expect_100", "Force sending an Expect: 100-continue header for 
POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
+{ "send_expect_100", "Force sending an Expect: 100-continue header for 
POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, E },
 { "location", "The actual location of the data received", 
OFFSET(location), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
 { "offset", "initial byte offset", OFFSET(off), AV_OPT_TYPE_INT64, { .i64 
= 0 }, 0, INT64_MAX, D },
 { "end_offset", "try to limit the request to bytes preceding this offset", 
OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
@@ -1179,7 +1180,10 @@ static int http_connect(URLContext *h, const char *path, 
const char *local_path,
 local_path, method);
 proxyauthstr = ff_http_auth_create_response(>proxy_auth_state, 
proxyauth,
 local_path, method);
-if (post && !s->post_data) {
+
+if (s->send_expect_100 != -1) {
+send_expect_100 = s->send_expect_100;
+} else if (post && !s->post_data) {
 send_expect_100 = s->send_expect_100;
 /* The user has supplied authentication but we don't know the auth 
type,
  * send Expect: 100-continue to get the 401 response including the
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
index c93b06b553..d2198b78ec 100644
--- a/libavformat/icecast.c
+++ b/libavformat/icecast.c
@@ -115,7 +115,7 @@ static int icecast_open(URLContext *h, const char *uri, int 
flags)
 av_dict_set(_dict, "auth_type", "basic", 0);
 av_dict_set(_dict, "headers", headers, 0);
 av_dict_set(_dict, "chunked_post", "0", 0);
-av_dict_set(_dict, "send_expect_100", s->legacy_icecast ? "0" : "1", 
0);
+av_dict_set(_dict, "send_expect_100", s->legacy_icecast ? "-1" : "1", 
0);
 if (NOT_EMPTY(s->content_type))
 av_dict_set(_dict, "content_type", s->content_type, 0);
 else
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ae8811234a..6e67e411b9 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1793,6 +1793,7 @@ redirect:
  sessioncookie);
 av_opt_set(rt->rtsp_hd_out->priv_data, "headers", headers, 0);
 av_opt_set(rt->rtsp_hd_out->priv_data, "chunked_post", "0", 0);
+av_opt_set(rt->rtsp_hd_out->priv_data, "send_expect_100", "0", 0);
 
 /* Initialize the authentication state for the POST session. The HTTP
  * protocol implementation doesn't properly handle multi-pass
-- 
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 2/2] avcodec/tiff: Multi-page support

2019-03-22 Thread Carl Eugen Hoyos 
2019-03-22 15:50 GMT+01:00, velocit...@gmail.com :
> From: Nick Renieris 
>
> Option "-page N" (page index N starts from 1) can now
> be used to specify which TIFF page/subfile to decode.

What is the current behaviour?
Shouldn't the decoder output all pages as for a video file?

Carl Eugen
___
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 v7] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

2019-03-22 Thread Michael Niedermayer 
On Fri, Mar 22, 2019 at 04:24:10PM +, Wang, Shaofei wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Michael Niedermayer
> > Sent: Friday, March 22, 2019 8:14 AM
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH v7] Improved the performance of 1
> > decode + N filter graphs and adaptive bitrate.
> > 
> > This changes the output for some cases like:
> > 
> > ./ffmpeg -y -i mm-short.mpg -flags +aic -qscale 2 -vcodec h263p -t 1  
> > -qscale
> > 10 old.avi
> > 
> > -rw-r- 1 michael michael 86434 Mar 22 01:07 new.avi
> > -rw-r- 1 michael michael 86402 Mar 22 01:07 old.avi
> > 
> > i assume this is unintended
> > 
> thanks
> tested several rounds which not reproduced
> what's the resolution of "mm-short.mpg"? it could not be very accurated in 
> terms of fps with the option "-t 1" which may bring a little bit more or less 
> output stream.

mm-short should simply be the first 2048000 bytes of matrixbench_mpeg2.mpg

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: PGP signature
___
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/flvdec: added support for KUX container

2019-03-22 Thread Swaraj Hota 
Okay I found "fmemopen()". I'll see if I can use it with
unzOpenCurrentFilePassword(). Please do tell if there
is a better solution though.
___
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/flvdec: added support for KUX container

2019-03-22 Thread Swaraj Hota 
I have the meta chunk loaded into a buffer.
I searched a lot but I couldn't find a way to decompress
a password protected zip buffer.

I saw zlib is used in the code base, so went through it.
Found a function "decompress()" but it didn't take a
password as argument. I found another function
under minizip/unzip.h called unzOpenCurrentFilePassword()
which does take password but it takes a file as an argument
and not a buffer.

I am not sure what to do. I thought of using mmap and pass
it to unzOpenCurrentFilePassword() but I guess its not
portable and might not work with windows. Or will it?
Please suggest something I can do here.
___
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] aac variable encoding

2019-03-22 Thread Dominik 'Rathann' Mierzejewski 
On Thursday, 21 March 2019 at 19:38, Yufei He wrote:
> Hi
> 
> On transcoding from 1080p .ts files to .mp4 files with my m264 codec, 
> audio of the output .mp4 files stutters.
> 
> We found audio of the stuttering files is vbr.
> 
> I did not set aac encoding bitrate. somehow it becomes vbr when I use my 
> m264 codec on transcoding 1080p files.
> 
> It works well for 1080i .ts files and all .mp4 and .mov files, and aac 
> audio of the output files is cbr.
> 
> So the problem is why aac encoding becomes vbr.
> 
> Command I use is:
> 
> ./ffmpeg -i TS/TSv2m2641080p30mcbr.ts  -vsync 0 -vcodec m264 -b:v 10M 
> 8_ff.mp4

THis is not a question related to development of FFmpeg but a question
about FFmpeg usage, therefore it belongs to the ffmpeg-user mailing
list: https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/

Please post such questions there in the future as they're off-topic
here.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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] avcodec/tiff: Multi-page support

2019-03-22 Thread Moritz Barsnick 
Hi Nich,

On Fri, Mar 22, 2019 at 17:55:56 +0200, velocit...@gmail.com wrote:
>  libavcodec/tiff.c | 25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
[...]
>  static const AVOption tiff_options[] = {
>  { "subimage", "decode subimage instead if available", 
> OFFSET(get_subimage), AV_OPT_TYPE_BOOL, {.i64=0},  0, 1, 
> AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM },
> +{ "page", "page number of multi-page image to decode (starting from 1)", 
> OFFSET(get_page), AV_OPT_TYPE_INT, {.i64=0}, 0, UINT16_MAX, 
> AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM },
>  { NULL },
>  };

I was about to write "could you please also update the documentation",
but just realized that the tiff encoder isn't documented. :-P

Cheers,
Moritz
___
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 v7] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

2019-03-22 Thread Wang, Shaofei 
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Michael Niedermayer
> Sent: Friday, March 22, 2019 8:14 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v7] Improved the performance of 1
> decode + N filter graphs and adaptive bitrate.
> 
> This changes the output for some cases like:
> 
> ./ffmpeg -y -i mm-short.mpg -flags +aic -qscale 2 -vcodec h263p -t 1  -qscale
> 10 old.avi
> 
> -rw-r- 1 michael michael 86434 Mar 22 01:07 new.avi
> -rw-r- 1 michael michael 86402 Mar 22 01:07 old.avi
> 
> i assume this is unintended
> 
thanks
tested several rounds which not reproduced
what's the resolution of "mm-short.mpg"? it could not be very accurated in 
terms of fps with the option "-t 1" which may bring a little bit more or less 
output stream.
___
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/tiff: Multi-page support

2019-03-22 Thread velocityra 
From: Nick Renieris 

Option "-page N" (page index N starts from 1) can now be used to specify which 
TIFF page/subfile to decode.

Signed-off-by: Nick Renieris 
---
 libavcodec/tiff.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 29a80a6892..9595681839 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -55,6 +55,7 @@ typedef struct TiffContext {
 GetByteContext gb;
 
 int get_subimage;
+uint16_t get_page;
 
 int width, height;
 unsigned int bpp, bppcount;
@@ -75,6 +76,7 @@ typedef struct TiffContext {
 unsigned white_level;
 
 uint32_t sub_ifd;
+uint16_t cur_page;
 
 int strips, rps, sstype;
 int sot;
@@ -1322,6 +1324,12 @@ static int tiff_decode_tag(TiffContext *s, AVFrame 
*frame)
 break;
 case TIFF_PAGE_NUMBER:
 ADD_METADATA(count, "page_number", " / ");
+// need to seek back to re-read the page number
+bytestream2_seek(>gb, -count * sizeof(uint16_t), SEEK_CUR);
+// read the page number
+s->cur_page = ff_tget(>gb, TIFF_SHORT, s->le);
+// get back to where we were before the previous seek
+bytestream2_seek(>gb, count * sizeof(uint16_t) - sizeof(uint16_t), 
SEEK_CUR);
 break;
 case TIFF_SOFTWARE_NAME:
 ADD_METADATA(count, "software", NULL);
@@ -1359,6 +1367,7 @@ static int decode_frame(AVCodecContext *avctx,
 uint8_t *dst;
 GetByteContext stripsizes;
 GetByteContext stripdata;
+int retry_for_subifd, retry_for_page;
 
 bytestream2_init(>gb, avpkt->data, avpkt->size);
 
@@ -1379,6 +1388,7 @@ again:
 s->fill_order  = 0;
 s->white_level = 0;
 s->is_bayer= 0;
+s->cur_page= 0;
 free_geotags(s);
 
 // Reset these offsets so we can tell if they were set this frame
@@ -1393,8 +1403,20 @@ again:
 return ret;
 }
 
-if (s->sub_ifd && s->get_subimage) {
+/** whether we should look for this IFD's SubIFD */
+retry_for_subifd = s->sub_ifd && s->get_subimage;
+/** whether we should look for this multi-page IFD's next page */
+retry_for_page = s->get_page && s->cur_page + 1 < s->get_page;  // 
get_page is 1-indexed
+
+if (retry_for_page) {
+// set offset to the next IFD
+off = ff_tget_long(>gb, le);
+} else if (retry_for_subifd) {
+// set offset to the SubIFD
 off = s->sub_ifd;
+}
+
+if (retry_for_subifd || retry_for_page) {
 if (off >= UINT_MAX - 14 || avpkt->size < off + 14) {
 av_log(avctx, AV_LOG_ERROR, "IFD offset is greater than image 
size\n");
 return AVERROR_INVALIDDATA;
@@ -1643,6 +1665,7 @@ static av_cold int tiff_end(AVCodecContext *avctx)
 #define OFFSET(x) offsetof(TiffContext, x)
 static const AVOption tiff_options[] = {
 { "subimage", "decode subimage instead if available", 
OFFSET(get_subimage), AV_OPT_TYPE_BOOL, {.i64=0},  0, 1, 
AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM },
+{ "page", "page number of multi-page image to decode (starting from 1)", 
OFFSET(get_page), AV_OPT_TYPE_INT, {.i64=0}, 0, UINT16_MAX, 
AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM },
 { NULL },
 };
 
-- 
2.21.0.windows.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] mxf file support

2019-03-22 Thread Yufei He 
Hi Tomas

Sony defined many kinds of meta data.

e.g. SMPTE RDD 18:2012

Acquisition Metadata Sets for
Video Camera Parameters

I think the file created by -vcodec copy is a general op1a mxf file.

It can not pass Sony's mxf file verifier, which means their camera can 
not play those files.

Yufei.


On 03/22/2019 11:11 AM, Tomas Härdin wrote:
> fre 2019-03-22 klockan 12:47 + skrev Yufei He:
>> Hi Tomas
>>
>>   From my tests, I find FFmpeg can demux XAVC mxf files from Sony and
>> find the video stream is actually h.264 data. This is very good to us.
>>
>> Actually Sony XAVC mxf has a lot of restrictions on mxf file wrapper and
>> h.264 data.
>>
>> But I don't know how to specify the it or it's not supported yet in FFmpeg.
>>
>> Probably we can support it if it's not there yet.
> This depends on what the restrictions are. The first step would be to
> just remux (-vcodec copy) the files and see what happens. If that
> doesn't work then mxfenc.c would need to be patched
>
> /Tomas
> ___
> 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".

Re: [FFmpeg-devel] [PATCH 1/2] avutil/opt: Add AV_OPT_TYPE_UINT16

2019-03-22 Thread Nick Renieris 
Yup, will do.
I made it before I realized there were size limits. Pushed a patch just in case.
___
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] mxf file support

2019-03-22 Thread Tomas Härdin 
fre 2019-03-22 klockan 12:47 + skrev Yufei He:
> Hi Tomas
> 
>  From my tests, I find FFmpeg can demux XAVC mxf files from Sony and 
> find the video stream is actually h.264 data. This is very good to us.
> 
> Actually Sony XAVC mxf has a lot of restrictions on mxf file wrapper and 
> h.264 data.
> 
> But I don't know how to specify the it or it's not supported yet in FFmpeg.
> 
> Probably we can support it if it's not there yet.

This depends on what the restrictions are. The first step would be to
just remux (-vcodec copy) the files and see what happens. If that
doesn't work then mxfenc.c would need to be patched

/Tomas
___
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 1/2] avutil/opt: Add AV_OPT_TYPE_UINT16

2019-03-22 Thread Hendrik Leppkes 
On Fri, Mar 22, 2019 at 4:01 PM  wrote:
>
> From: Nick Renieris 
>
> Signed-off-by: Nick Renieris 
> ---
>  libavutil/opt.c | 29 +++--
>  libavutil/opt.h |  1 +
>  2 files changed, 28 insertions(+), 2 deletions(-)
>

We really don't need this type. You can just change the type of your
variable to int and set size limits on the option.

- Hendrik
___
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 1/2] avutil/opt: Add AV_OPT_TYPE_UINT16

2019-03-22 Thread velocityra 
From: Nick Renieris 

Signed-off-by: Nick Renieris 
---
 libavutil/opt.c | 29 +++--
 libavutil/opt.h |  1 +
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/libavutil/opt.c b/libavutil/opt.c
index 93d6c26c11..d409f3521a 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -71,6 +71,9 @@ static int read_number(const AVOption *o, const void *dst, 
double *num, int *den
 case AV_OPT_TYPE_INT:
 *intnum = *(int *)dst;
 return 0;
+case AV_OPT_TYPE_UINT16:
+*intnum = *(uint16_t*)dst;
+return 0;
 case AV_OPT_TYPE_CHANNEL_LAYOUT:
 case AV_OPT_TYPE_DURATION:
 case AV_OPT_TYPE_INT64:
@@ -125,6 +128,13 @@ static int write_number(void *obj, const AVOption *o, void 
*dst, double num, int
 case AV_OPT_TYPE_INT:
 *(int *)dst = llrint(num / den) * intnum;
 break;
+case AV_OPT_TYPE_UINT16:{
+float d = num / den;
+if (intnum == 1 && d == (float)UINT16_MAX) {
+*(int16_t *)dst = INT16_MAX;
+} else
+*(int16_t *)dst = llrint(d) * intnum;
+break;}
 case AV_OPT_TYPE_DURATION:
 case AV_OPT_TYPE_CHANNEL_LAYOUT:
 case AV_OPT_TYPE_INT64:{
@@ -218,8 +228,9 @@ static int set_string(void *obj, const AVOption *o, const 
char *val, uint8_t **d
 return *dst ? 0 : AVERROR(ENOMEM);
 }
 
-#define DEFAULT_NUMVAL(opt) ((opt->type == AV_OPT_TYPE_INT64 || \
-  opt->type == AV_OPT_TYPE_UINT64 || \
+#define DEFAULT_NUMVAL(opt) ((opt->type == AV_OPT_TYPE_UINT16 ||\
+  opt->type == AV_OPT_TYPE_UINT64 ||\
+  opt->type == AV_OPT_TYPE_INT64 || \
   opt->type == AV_OPT_TYPE_CONST || \
   opt->type == AV_OPT_TYPE_FLAGS || \
   opt->type == AV_OPT_TYPE_INT) \
@@ -476,6 +487,7 @@ int av_opt_set(void *obj, const char *name, const char 
*val, int search_flags)
 return set_string_binary(obj, o, val, dst);
 case AV_OPT_TYPE_FLAGS:
 case AV_OPT_TYPE_INT:
+case AV_OPT_TYPE_UINT16:
 case AV_OPT_TYPE_INT64:
 case AV_OPT_TYPE_UINT64:
 case AV_OPT_TYPE_FLOAT:
@@ -785,6 +797,9 @@ int av_opt_get(void *obj, const char *name, int 
search_flags, uint8_t **out_val)
 case AV_OPT_TYPE_INT:
 ret = snprintf(buf, sizeof(buf), "%d", *(int *)dst);
 break;
+case AV_OPT_TYPE_UINT16:
+ret = snprintf(buf, sizeof(buf), "%"PRIu16, *(uint16_t *)dst);
+break;
 case AV_OPT_TYPE_INT64:
 ret = snprintf(buf, sizeof(buf), "%"PRId64, *(int64_t *)dst);
 break;
@@ -1136,6 +1151,9 @@ static void opt_list(void *obj, void *av_log_obj, const 
char *unit,
 case AV_OPT_TYPE_INT:
 av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
 break;
+case AV_OPT_TYPE_UINT16:
+av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
+break;
 case AV_OPT_TYPE_INT64:
 av_log(av_log_obj, AV_LOG_INFO, "%-12s ", "");
 break;
@@ -1202,6 +1220,7 @@ static void opt_list(void *obj, void *av_log_obj, const 
char *unit,
 if (av_opt_query_ranges(, obj, opt->name, AV_OPT_SEARCH_FAKE_OBJ) >= 
0) {
 switch (opt->type) {
 case AV_OPT_TYPE_INT:
+case AV_OPT_TYPE_UINT16:
 case AV_OPT_TYPE_INT64:
 case AV_OPT_TYPE_UINT64:
 case AV_OPT_TYPE_DOUBLE:
@@ -1248,6 +1267,7 @@ static void opt_list(void *obj, void *av_log_obj, const 
char *unit,
 break;
 }
 case AV_OPT_TYPE_INT:
+case AV_OPT_TYPE_UINT16:
 case AV_OPT_TYPE_UINT64:
 case AV_OPT_TYPE_INT64: {
 const char *def_const = get_opt_const_name(obj, opt->unit, 
opt->default_val.i64);
@@ -1326,6 +1346,7 @@ void av_opt_set_defaults2(void *s, int mask, int flags)
 case AV_OPT_TYPE_BOOL:
 case AV_OPT_TYPE_FLAGS:
 case AV_OPT_TYPE_INT:
+case AV_OPT_TYPE_UINT16:
 case AV_OPT_TYPE_INT64:
 case AV_OPT_TYPE_UINT64:
 case AV_OPT_TYPE_DURATION:
@@ -1685,6 +1706,8 @@ static int opt_size(enum AVOptionType type)
 case AV_OPT_TYPE_INT:
 case AV_OPT_TYPE_FLAGS:
 return sizeof(int);
+case AV_OPT_TYPE_UINT16:
+return sizeof(uint16_t);
 case AV_OPT_TYPE_DURATION:
 case AV_OPT_TYPE_CHANNEL_LAYOUT:
 case AV_OPT_TYPE_INT64:
@@ -1817,6 +1840,7 @@ int av_opt_query_ranges_default(AVOptionRanges 
**ranges_arg, void *obj, const ch
 switch (field->type) {
 case AV_OPT_TYPE_BOOL:
 case AV_OPT_TYPE_INT:
+case AV_OPT_TYPE_UINT16:
 case AV_OPT_TYPE_INT64:
 case AV_OPT_TYPE_UINT64:
 case AV_OPT_TYPE_PIXEL_FMT:
@@ -1905,6 +1929,7 @@ int av_opt_is_set_to_default(void *obj, const AVOption *o)
 case AV_OPT_TYPE_PIXEL_FMT:
 case

[FFmpeg-devel] [PATCH 2/2] avcodec/tiff: Multi-page support

2019-03-22 Thread velocityra 
From: Nick Renieris 

Option "-page N" (page index N starts from 1) can now be used to specify which 
TIFF page/subfile to decode.

Signed-off-by: Nick Renieris 
---
 libavcodec/tiff.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 29a80a6892..94ff4bd394 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -55,6 +55,7 @@ typedef struct TiffContext {
 GetByteContext gb;
 
 int get_subimage;
+uint16_t get_page;
 
 int width, height;
 unsigned int bpp, bppcount;
@@ -75,6 +76,7 @@ typedef struct TiffContext {
 unsigned white_level;
 
 uint32_t sub_ifd;
+uint16_t cur_page;
 
 int strips, rps, sstype;
 int sot;
@@ -1322,6 +1324,12 @@ static int tiff_decode_tag(TiffContext *s, AVFrame 
*frame)
 break;
 case TIFF_PAGE_NUMBER:
 ADD_METADATA(count, "page_number", " / ");
+// need to seek back to re-read the page number
+bytestream2_seek(>gb, -count * sizeof(uint16_t), SEEK_CUR);
+// read the page number
+s->cur_page = ff_tget(>gb, TIFF_SHORT, s->le);
+// get back to where we were before the previous seek
+bytestream2_seek(>gb, count * sizeof(uint16_t) - sizeof(uint16_t), 
SEEK_CUR);
 break;
 case TIFF_SOFTWARE_NAME:
 ADD_METADATA(count, "software", NULL);
@@ -1359,6 +1367,7 @@ static int decode_frame(AVCodecContext *avctx,
 uint8_t *dst;
 GetByteContext stripsizes;
 GetByteContext stripdata;
+int retry_for_subifd, retry_for_page;
 
 bytestream2_init(>gb, avpkt->data, avpkt->size);
 
@@ -1379,6 +1388,7 @@ again:
 s->fill_order  = 0;
 s->white_level = 0;
 s->is_bayer= 0;
+s->cur_page= 0;
 free_geotags(s);
 
 // Reset these offsets so we can tell if they were set this frame
@@ -1393,8 +1403,20 @@ again:
 return ret;
 }
 
-if (s->sub_ifd && s->get_subimage) {
+/** whether we should look for this IFD's SubIFD */
+retry_for_subifd = s->sub_ifd && s->get_subimage;
+/** whether we should look for this multi-page IFD's next page */
+retry_for_page = s->get_page && s->cur_page + 1 < s->get_page;  // 
get_page is 1-indexed
+
+if (retry_for_page) {
+// set offset to the next IFD
+off = ff_tget_long(>gb, le);
+} else if (retry_for_subifd) {
+// set offset to the SubIFD
 off = s->sub_ifd;
+}
+
+if (retry_for_subifd || retry_for_page) {
 if (off >= UINT_MAX - 14 || avpkt->size < off + 14) {
 av_log(avctx, AV_LOG_ERROR, "IFD offset is greater than image 
size\n");
 return AVERROR_INVALIDDATA;
@@ -1643,6 +1665,7 @@ static av_cold int tiff_end(AVCodecContext *avctx)
 #define OFFSET(x) offsetof(TiffContext, x)
 static const AVOption tiff_options[] = {
 { "subimage", "decode subimage instead if available", 
OFFSET(get_subimage), AV_OPT_TYPE_BOOL, {.i64=0},  0, 1, 
AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM },
+{ "page", "page number of multi-page image to decode (starting from 1)", 
OFFSET(get_page), AV_OPT_TYPE_UINT16, {.i64=0}, 0, UINT16_MAX, 
AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM },
 { NULL },
 };
 
-- 
2.21.0.windows.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] mxf file support

2019-03-22 Thread Yufei He 
Hi Tomas

 From my tests, I find FFmpeg can demux XAVC mxf files from Sony and 
find the video stream is actually h.264 data. This is very good to us.

Actually Sony XAVC mxf has a lot of restrictions on mxf file wrapper and 
h.264 data.

But I don't know how to specify the it or it's not supported yet in FFmpeg.

Probably we can support it if it's not there yet.

Yufei.


On 03/21/2019 06:09 PM, Tomas Härdin wrote:
> tor 2019-03-21 klockan 18:48 + skrev Yufei He:
>> Hi
>>
>> It seems FFmpeg supports reading all kinds of mxf files from Sony and
>> Panasonics. it's very good to find that FFmpeg can support Sony XAVC
>> QuadHD files and find the essence data is actually H.264.
>>
>> Our customers have a lot of high data rate mxf files from Sony and
>> Panasonics. They need transcode those files to streaming files like
>> .ts,.mp4, etc.
> Here it sounds like you you want to demux Sony XAVC MXFs..
>
>> Does FFmpeg supports writing Sony XAVC mxf files ?
> and here it sounds like you want to mux them.
>
> It's certainly possible to ape whatever peculiaritites Sony has for its
> MXF muxer, I've done similar things with MXF in the past.
>
> /Tomas
> ___
> 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".

Re: [FFmpeg-devel] Add 16-bit Depth pixel format

2019-03-22 Thread Carl Eugen Hoyos 
2019-03-21 1:26 GMT+01:00, Carl Eugen Hoyos :
> 2018-11-19 18:41 GMT+01:00, Carl Eugen Hoyos :
>> 2018-11-19 18:21 GMT+01:00, Pablo Rubio Fernández
>> :
>>
>>> It's my first time here. I want to create a patch to add
>>> Z16 pixel format.
>>> I have did some changes, and I want to know if I'll need
>>> change any other file.
>>
>> Isn't attached poc sufficient?
>
> Patch attached that imo makes using z16 a little easier,
> will push if there are no objections.

Patch applied.

Carl Eugen
___
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] Fix sdp size check on fmtp integer parameters

2019-03-22 Thread Olivier Maignial 
RFC-4566 do not give any limit of size on interger parameters given in fmtp 
line.
By reading some more RFCs it is possible to find examples where some integers 
parameters are greater than 32 (see RFC-6416, 7.4)

Instead I propose to check just check the eventual integer overflow.
Using INT_MIN and INT_MAX ensure that it will work whatever the size of int 
given by compiler
---
 libavformat/rtpdec_mpeg4.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
index 994ab49..14caa0a 100644
--- a/libavformat/rtpdec_mpeg4.c
+++ b/libavformat/rtpdec_mpeg4.c
@@ -289,15 +289,23 @@ static int parse_fmtp(AVFormatContext *s,
 for (i = 0; attr_names[i].str; ++i) {
 if (!av_strcasecmp(attr, attr_names[i].str)) {
 if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
-int val = atoi(value);
-if (val > 32) {
+char *end_ptr = NULL;
+long int val = strtol(value, _ptr, 10);
+if (value[0] == '\n' || end_ptr[0] != '\0') {
 av_log(s, AV_LOG_ERROR,
-   "The %s field size is invalid (%d)\n",
+   "The %s field value is not a number (%s)\n",
+   attr, value);
+return AVERROR_INVALIDDATA;
+}
+
+if (val > INT_MAX || val < INT_MIN) {
+av_log(s, AV_LOG_ERROR,
+   "The %s field size is invalid (%ld)\n",
attr, val);
 return AVERROR_INVALIDDATA;
 }
 *(int *)((char *)data+
-attr_names[i].offset) = val;
+attr_names[i].offset) = (int) val;
 } else if (attr_names[i].type == ATTR_NAME_TYPE_STR) {
 char *val = av_strdup(value);
 if (!val)
-- 
2.7.4

___
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/mpegtsenc: added support for the write_data_type callback

2019-03-22 Thread Oliver Collyer via ffmpeg-devel 
> 
> This patch makes it possible to do stuff like write a custom in-memory TS 
> segmenter, which was what I needed it for.
> 
>> Hi
>> 
>> I needed to be able to use the write_data_type callback when reading data 
>> from the mpegts muxer, to make my application aware of key frames in the 
>> data so I added support. I used the matroska implementation as a reference.
>> 
>> If this is accepted, I will format this as a proper patch after feedback.
>> 
>> Regards
>> 
>> Oliver
>> 
>> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
>> index fc0ea225c6..e5d1a64b4c 100644
>> --- a/libavformat/mpegtsenc.c
>> +++ b/libavformat/mpegtsenc.c
>> @@ -1815,6 +1815,12 @@ static int mpegts_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>  mpegts_write_flush(s);
>>  return 1;
>>  } else {
>> +if (s->pb && s->pb->write_data_type) {
>> +AVStream *st = s->streams[pkt->stream_index];
>> +avio_write_marker(s->pb,
>> +av_rescale_q(pkt->dts, st->time_base, AV_TIME_BASE_Q),
>> +(pkt->flags & AV_PKT_FLAG_KEY) && st->codecpar->codec_type 
>> == AVMEDIA_TYPE_VIDEO ? AVIO_DATA_MARKER_SYNC_POINT : 
>> AVIO_DATA_MARKER_BOUNDARY_POINT);
>> +}
>>  return mpegts_write_packet_internal(s, pkt);
>>  }
>> }
>> 
> 
> So I've created a patch for this.
> 
> <0001-mpegtsenc-added-support-for-the-write_data_type-call.patch>

Ping, for this really trivial patch.

___
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 v1 1/1] vaapi_hevc: Fix double-free issue.

2019-03-22 Thread Lin, Decai 


> -Original Message-
> From: Fu, Linjie
> Sent: 2019年3月21日 20:20
> To: FFmpeg development discussions and patches
> 
> Cc: Yan, FengX ; Lin, Decai 
> Subject: RE: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free
> issue.
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Decai Lin
> > Sent: Thursday, March 21, 2019 17:30
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Yan, FengX ; Lin, Decai 
> > Subject: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue.
> >
> > From: "Yan, FengX" 
> >
> > Signed-off-by: Yan, FengX 
> > Signed-off-by: Decai Lin 
> > ---
> >  libavcodec/vaapi_hevc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c index
> > 19aabcd..373ffc4 100644
> > --- a/libavcodec/vaapi_hevc.c
> > +++ b/libavcodec/vaapi_hevc.c
> > @@ -271,7 +271,7 @@ static int vaapi_hevc_end_frame(AVCodecContext
> > *avctx)
> >
> >  ret = ff_vaapi_decode_issue(avctx, >pic);
> >  if (ret < 0)
> > -goto fail;
> > +return ret;
> >
> >  return 0;
> >  fail:
> 
> I believe this should match the behavior in vaapi_h264/mpeg4/.../vc1.c, and
> remove the redundant  ff_vaapi_decode_cancel in vaapi_hevc_end_frame().
> 
> --Linjie

Hello Linjie, there is little different between vaapi_hevc and other vaapi 
codecs. 
vaapi_hevc has an extra code block to handle slice buffer before 
ff_vaapi_decode_issue() , and if it's failed to handle, the buffers have to be 
destroyed separately.
So the calling of ff_vaapi_decode_cancel() here is a must for hevc. 

___
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".