Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
- Original Message - From: Kieran Kunhya kier...@obe.tv To: Wiebe Cazemier wi...@halfgaar.net Sent: Monday, 30 March, 2015 3:43:42 AM Subject: Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default It's in the spec as an *option*, to cater to those who have bad sound systems. If ffmpeg already applies DRC, and software using ffmpeg doesn't set 'drc_scale', it's no longer an option, it becomes mandatory. That's the issue. It is not an option and I quote ETSI 102 366: Therefore, the AC-3 decoder shall, by default, implement the compression characteristic indicated by the dynrng values in the data stream. AC-3 decoders may optionally allow listener control over the use of the dynrng values, so that the listener may select full or partial dynamic range reproduction. If an application doesn't want to expose drc settings then that's their problem. FFmpeg does the right thing and lets you turn it off if you wish. Kieran (can you reply-all, so that your reply goes to the list?) If you say it's not an option, that's putting it harder than the spec say. Dolby engineers never meant AC3 audio to be played compressed everywhere, and that's what we're seeing happening. Also, I feel that the word 'decoder' in your quote is written in a time where it had a different context and that quote has to be interpreted that way. Open source software libraries weren't available at that point, and a decoder was a piece of hardware, or a chip embedded in something. Sure, you don't have to allow the user to control it when you embed an AC3 decoder in your budget TV so ATSC demanding that you do would be silly here, but all high end receivers I know, do allow you to set the option. Now that we do have a library that people can use, an honest mistake to forget to implement it turns into something that they probably didn't intend. As proven by the Kodi developer denying that they applied DRC. I think we have to consider user experience, and it's great when they can control it, but we're getting the situation where everybody gets it (yet only for AC3), whether they want to or not. That automatically crosses off Kodi and VLC (for example) for use in high quality sound reproduction. And the bad thing is, they may not even know it... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
- Original Message - From: Kieran Kunhya kier...@obe.tv To: Wiebe Cazemier wi...@halfgaar.net Sent: Monday, 30 March, 2015 10:47:49 AM Subject: Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default It is not an option and I quote ETSI 102 366: Therefore, the AC-3 decoder shall, by default, implement the compression characteristic indicated by the dynrng values in the data stream. AC-3 decoders may optionally allow listener control over the use of the dynrng values, so that the listener may select full or partial dynamic range reproduction. If an application doesn't want to expose drc settings then that's their problem. FFmpeg does the right thing and lets you turn it off if you wish. Kieran (can you reply-all, so that your reply goes to the list?) If you say it's not an option, that's putting it harder than the spec say. Dolby engineers never meant AC3 audio to be played compressed everywhere, and that's what we're seeing happening. Also, I feel that the word 'decoder' in your quote is written in a time where it had a different context and that quote has to be interpreted that way. Open source software libraries weren't available at that point, and a decoder was a piece of hardware, or a chip embedded in something. Sure, you don't have to allow the user to control it when you embed an AC3 decoder in your budget TV so ATSC demanding that you do would be silly here, but all high end receivers I know, do allow you to set the option. Now that we do have a library that people can use, an honest mistake to forget to implement it turns into something that they probably didn't intend. As proven by the Kodi developer denying that they applied DRC. I think we have to consider user experience, and it's great when they can control it, but we're getting the situation where everybody gets it (yet only for AC3), whether they want to or not. That automatically crosses off Kodi and VLC (for example) for use in high quality sound reproduction. And the bad thing is, they may not even know it... It's the complete opposite - most people are watching on laptop speakers without the dynamic range you have in your setup. FFmpeg lets you turn it off and it's the fault of the player for not exposing that. What about those people playing AAC, which is the majority currently. In any case, I made my point. How do we proceed? I have no idea who is in charge of what, and how the decision making process goes in ffmpeg development. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
From: Kieran Kunhya kier...@obe.tv To: Wiebe Cazemier wi...@halfgaar.net Sent: Monday, 30 March, 2015 3:43:42 AM Subject: Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default It is not an option and I quote ETSI 102 366: Therefore, the AC-3 decoder shall, by default, implement the compression characteristic indicated by the dynrng values in the data stream. AC-3 decoders may optionally allow listener control over the use of the dynrng values, so that the listener may select full or partial dynamic range reproduction. Let me ask you: The DVD and Blu-Ray specs require that a DVD/Blu-Ray player not allow the user to skip forced video parts (like anti-piracy clips or sometimes even trailers). So since the spec says so, we should make sure that all open source media players also follow the spec to the letter and not allow users to skip forced video clips? Is that truly your opinion? And if the spec asks you to shoot yourself in the foot, you do that, too? How about using some common sense: What should have priority? The best user experience? Or following some stupid instructions in a spec? As I said before, the only situation where the default value matters (and we're only asking to change the default value, not to remove the ability to apply dynamic range compression altogether) is when the software using ffmpeg is not aware that there is such a thing as the drc_scale option. In this situation of course you can blame the software. But the end result is that the end user experience will suffer, because ffmpeg will output subpar quality in that situation. What good is that for anybody? What do you think would happen if we started a vote like the following: 1) Should ffmpeg output reduced (range compressed) audio quality by default, because the spec says so? 2) Should ffmpeg output full (range) quality by default, unless the software asks ffmpeg to do otherwise? How many users or devs would vote for 1) or 2)? And you didn't answer the question I asked before: Why would only AC3 have range compression on by default? Why not any other codec? What is the sense in that?? Are you saying that laptop speakers are not able to play full range AC3 tracks, but that they *are* able to play full range TrueHD tracks? If you truly believe that range compression should be on by default, then you should be consistent about it, and ask for range compression to be enabled by default for all other audio decoders, too. We're intelligent beings, we don't have to blindly follow everything some stupid spec says. Best regards, Mathias. 2015-03-30 9:38 GMT+02:00 Wiebe Cazemier wi...@halfgaar.net: - Original Message - From: Kieran Kunhya kier...@obe.tv To: Wiebe Cazemier wi...@halfgaar.net Sent: Monday, 30 March, 2015 3:43:42 AM Subject: Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default It's in the spec as an *option*, to cater to those who have bad sound systems. If ffmpeg already applies DRC, and software using ffmpeg doesn't set 'drc_scale', it's no longer an option, it becomes mandatory. That's the issue. It is not an option and I quote ETSI 102 366: Therefore, the AC-3 decoder shall, by default, implement the compression characteristic indicated by the dynrng values in the data stream. AC-3 decoders may optionally allow listener control over the use of the dynrng values, so that the listener may select full or partial dynamic range reproduction. If an application doesn't want to expose drc settings then that's their problem. FFmpeg does the right thing and lets you turn it off if you wish. Kieran (can you reply-all, so that your reply goes to the list?) If you say it's not an option, that's putting it harder than the spec say. Dolby engineers never meant AC3 audio to be played compressed everywhere, and that's what we're seeing happening. Also, I feel that the word 'decoder' in your quote is written in a time where it had a different context and that quote has to be interpreted that way. Open source software libraries weren't available at that point, and a decoder was a piece of hardware, or a chip embedded in something. Sure, you don't have to allow the user to control it when you embed an AC3 decoder in your budget TV so ATSC demanding that you do would be silly here, but all high end receivers I know, do allow you to set the option. Now that we do have a library that people can use, an honest mistake to forget to implement it turns into something that they probably didn't intend. As proven by the Kodi developer denying that they applied DRC. I think we have to consider user experience, and it's great when they can control it, but we're getting the situation where everybody gets it (yet only for AC3), whether they want to or not. That automatically crosses off Kodi and VLC (for example) for use in high quality sound reproduction. And
[FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata
Some software mis decodes IMX material in mxf if this metadata field is
missing. See the discussion on the ffmpeg ML:-
[FFmpeg-user] How to set 3 specific metadata flags
(ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?
This patch add this field to mxf wrapped material.
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
From 7ab1565acb1320a6eaafd47cbae86a8415419274 Mon Sep 17 00:00:00 2001
From: Tim Nicholson tim.nichol...@bbc.co.uk
Date: Mon, 30 Mar 2015 11:11:17 +0100
Subject: [PATCH] libavformat/mxfenc.c: Add 'Presentation Y offset' metadata
Previously unset, and some software mishandles files if it is absent
Signed-off-by: Tim Nicholson tim.nichol...@bbc.co.uk
---
libavformat/mxfenc.c | 7 ++-
tests/ref/lavf/mxf| 6 +++---
tests/ref/lavf/mxf_d10| 2 +-
tests/ref/lavf/mxf_opatom | 2 +-
4 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index ac60357..7b400b3 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -406,6 +406,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
{ 0x3202, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x02,0x01,0x00,0x00,0x00}}, /* Stored Height */
{ 0x3209, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0C,0x00,0x00,0x00}}, /* Display Width */
{ 0x3208, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0B,0x00,0x00,0x00}}, /* Display Height */
+{ 0x320B, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0E,0x00,0x00,0x00}}, /* Presentation Y offset */
{ 0x320E, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x00,0x00,0x00}}, /* Aspect Ratio */
{ 0x3201, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x06,0x01,0x00,0x00,0x00,0x00}}, /* Picture Essence Coding */
{ 0x3212, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x03,0x01,0x06,0x00,0x00,0x00}}, /* Field Dominance (Opt) */
@@ -978,7 +979,7 @@ static void mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID ke
int stored_height = (st-codec-height+15)/16*16;
int display_height;
int f1, f2;
-unsigned desc_size = size+8+8+8+8+8+8+5+16+sc-interlaced*4+12+20;
+unsigned desc_size = size+8+8+8+8+8+8+8+5+16+sc-interlaced*4+12+20;
if (sc-interlaced sc-field_dominance)
desc_size += 5;
@@ -1003,6 +1004,10 @@ static void mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID ke
mxf_write_local_tag(pb, 4, 0x3208);
avio_wb32(pb, display_heightsc-interlaced);
+// presentation Y offset
+mxf_write_local_tag(pb, 4, 0x320B);
+avio_wb32(pb, (st-codec-height - display_height)sc-interlaced);
+
// component depth
mxf_write_local_tag(pb, 4, 0x3301);
avio_wb32(pb, sc-component_depth);
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index 8ead434..5fb984b 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-306708cc2ad2414def89fa2f3c0bfc5c *./tests/data/lavf/lavf.mxf
+613b160bf09927661d9455dd975ad780 *./tests/data/lavf/lavf.mxf
525369 ./tests/data/lavf/lavf.mxf
./tests/data/lavf/lavf.mxf CRC=0xdbfff6f1
-f465084f0c365926a81aab56fb6b945c *./tests/data/lavf/lavf.mxf
+64471cfc480751f2ca7998c4edbc7a02 *./tests/data/lavf/lavf.mxf
560697 ./tests/data/lavf/lavf.mxf
./tests/data/lavf/lavf.mxf CRC=0x11a6178e
-52fc707e1177c97232e2537168c232e6 *./tests/data/lavf/lavf.mxf
+a546bd6d8fe1608690bf2fc326cab0c3 *./tests/data/lavf/lavf.mxf
525369 ./tests/data/lavf/lavf.mxf
./tests/data/lavf/lavf.mxf CRC=0xdbfff6f1
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index 71707ca..8201557 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-8f601d5b55a0665cc105a115dc8b3af0 *./tests/data/lavf/lavf.mxf_d10
+22dca5c8d62fe7ad1c56416ae736d6c1 *./tests/data/lavf/lavf.mxf_d10
5330989 ./tests/data/lavf/lavf.mxf_d10
./tests/data/lavf/lavf.mxf_d10 CRC=0x6c74d488
diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
index 5529e5b..0dd59c1 100644
--- a/tests/ref/lavf/mxf_opatom
+++ b/tests/ref/lavf/mxf_opatom
@@ -1,3 +1,3 @@
-0f753a141424e2a1b44e6390f70172eb *./tests/data/lavf/lavf.mxf_opatom
+5df0bb1083cbe0ef3a70e4a93e44d812 *./tests/data/lavf/lavf.mxf_opatom
4717113 ./tests/data/lavf/lavf.mxf_opatom
./tests/data/lavf/lavf.mxf_opatom CRC=0xbdd696b9
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
And you didn't answer the question I asked before: Why would only AC3 have range compression on by default? Why not any other codec? What is the sense in that?? Are you saying that laptop speakers are not able to play full range AC3 tracks, but that they *are* able to play full range TrueHD tracks? If you truly believe that range compression should be on by default, then you should be consistent about it, and ask for range compression to be enabled by default for all other audio decoders, too. We're intelligent beings, we don't have to blindly follow everything some stupid spec says. We should have DRC enabled in AAC and other codecs if it's considered a normative part of the spec. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] UDP Multicast
Andre Lopes wrote:
H
I was trying to setup a ffmpeg client to work with an Arecont camera in
multicast and realized that the camera would only return a multicast stream
after an RSTP call, if the SETUP was requested with the following transport:
Transport: RTP/AVP;multicast;client_port=x
Since the current implementation of the FFMpeg client is sending the transport
the values RTP/AVP/UDP;multicast and this was not being recognized by the
camera, I have changed the FFMpeg code to send the required transport
definition. This way the client started to receive a multicast stream from the
camera.
The diff is the following:
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index c9ffba4..ecbfdf5 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1451,7 +1451,7 @@ int ff_rtsp_make_setup_request(AVFormatContext *s, const
char *host, int port,
else if (lower_transport == RTSP_LOWER_TRANSPORT_UDP_MULTICAST) {
snprintf(transport, sizeof(transport) - 1,
- %s/UDP;multicast, trans_pref);
+ %s;multicast;client_port=%d-%d, trans_pref,
rtsp_st-sdp_port, rtsp_st-sdp_port + 1);
You are right, UDP is the default transport protocol and /UDP could be
omitted - see RFC 2326. But your camery should be able to parse
RTP/AVP/UDP correctly. So, I think the following line should also work
in your case - does it?:
+ %s/UDP;multicast;client_port=%d-%d, trans_pref,
rtsp_st-sdp_port, rtsp_st-sdp_port + 1);
If this is the case I would prefer this solution to keep the code
similar to the RTP/UDP unicast case.
}
if (s-oformat) {
av_strlcat(transport, ;mode=record, sizeof(transport));
Could this patch be included in the ffmpeg code?
Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
On Mon, Mar 30, 2015 at 11:28:29AM +0100, Kieran Kunhya wrote: On 30 March 2015 at 11:24, madshi mad...@gmail.com wrote: 2015-03-30 12:10 GMT+02:00 Kieran Kunhya kier...@obe.tv: We should have DRC enabled in AAC and other codecs if it's considered a normative part of the spec. So basically you do what the spec says regardless of whether it makes sense or not? Yes, for FFmpeg, this is not true. ISO mpeg4 specified one way to do QPEL, but the reference implementation did it the other way. Our decoder tries hard to figure out which of the 2 was used on the encoder side and matches it when decoding. IIRC the mpeg4 spec was changed to match the implementation at some point then as well Some mpeg4 encoders do the edge handling for MC wrong, we detect them and match it in the decoder. That way the user sees a nice video instead of one with minor or not so minor artifacts. We clearly violate a normative part of the spec by displaying these videos without artifacts we also detect some ancient buggy version of x264 and decode that different from what the spec would require to match what the encoder did, the above examples are of course bug workarounds but then there is no spec that says output video with a modified gamma compared to the encoder input unless the user override that or does one ? [...] and we let power users change things from the API - I don't see why that's so hard. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
On Sun, Mar 29, 2015 at 07:01:08PM +0200, Wiebe Cazemier wrote:
Signed-off-by: Wiebe Cazemier wi...@halfgaar.net
---
Changelog | 1 +
doc/decoders.texi | 2 +-
libavcodec/ac3dec_fixed.c | 2 +-
libavcodec/ac3dec_float.c | 2 +-
libavutil/version.h | 2 +-
5 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Changelog b/Changelog
index 109a1b8..0bd9875 100644
--- a/Changelog
+++ b/Changelog
@@ -11,6 +11,7 @@ version next:
- nvenc H265 encoder
- Detelecine filter
- Intel QSV-accelerated H.264 encoding
+- Dolby Digital dynamic range compression disabled by default
version 2.6:
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 01fca9f..ba78a31 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -72,7 +72,7 @@ from the AC-3 stream. This factor is applied exponentially.
There are 3 notable scale factor ranges:
@table @option
@item drc_scale == 0
-DRC disabled. Produces full range audio.
+DRC disabled. Produces full range audio. Default value.
@item 0 drc_scale = 1
DRC enabled. Applies a fraction of the stream DRC value.
Audio reproduction is between full range and full compression.
diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
index b4beee6..e3c8ce8 100644
--- a/libavcodec/ac3dec_fixed.c
+++ b/libavcodec/ac3dec_fixed.c
@@ -168,7 +168,7 @@ static void ac3_downmix_c_fixed16(int16_t **samples,
int16_t (*matrix)[2],
#include ac3dec.c
static const AVOption options[] = {
-{ drc_scale, percentage of dynamic range compression to apply,
OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
+{ drc_scale, percentage of dynamic range compression to apply,
OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 0.0}, 0.0, 6.0, PAR },
{ heavy_compr, heavy dynamic range compression enabled,
OFFSET(heavy_compression), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 1, PAR },
{ NULL},
it might make sense to add a -1 value to drc_scale with the
meaining do what the spec says
this way if 2 decoders in the future support the drc_scale option
it would be possible for a user to set them to use the defaults
from their specs even if these defaults differ
but this should be a seperate patch of course, so arguable that isnt
a comment about this patch
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
Michael Niedermayer wrote: Apologies for the slightly out of place response. I've only just subscribed after reading the rest of this thread via the archive. I'm with KieranK the exception should be full range for those that can stand it. Maybe I am not best placed to comment as I mixdown to 2ch, but while people here argue that full range is better quality, I would agree a bit, but unfortunately many movies are mixed in such a way that in order to hear the dialogue the loud bits become way way too loud for comfort. The argument that DTS/AAC/TrueHD decs don't do it IMHO is invalid as in the latter two cases at least this is only due to incomplete (and from my pov sometimes therefore unusable) implementations. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] WIP: lavf/segment: provide a virtual AVIOContext representing all the segments
On Sun, Mar 29, 2015 at 10:07:21PM -0600, Rodger Combs wrote: This needs a fair bit of testing and review before merge. Re: mini: If you wish to shorten my name please use mn, its fewer keys, so you safe some time if the header does get updated at the end this would mismatch if only a subset of segments get concatenated This is one reason why I have the `seekback` option disabled by default (the other being that it avoids potential interprocess races) ok, i tested a bit and it seems: ./ffmpeg -i randomfile.mpg -f ssegment -t 4 -segment_time 1.5 -individual_header_trailer 0 file.%4d.ts results in a missing file..ts segments starting from 0001 instead [...] /* copy modified name in list entry */ size = strlen(av_basename(oc-filename)) + 1; + if (seg-entry_prefix) size += strlen(seg-entry_prefix); @@ -226,19 +355,23 @@ static int segment_start(AVFormatContext *s, int write_header) } seg-segment_idx++; -if ((seg-segment_idx_wrap) (seg-segment_idx%seg-segment_idx_wrap == 0)) +if ((seg-segment_idx_wrap) (seg-segment_idx % seg-segment_idx_wrap == 0)) unrelated [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata
On Mon, Mar 30, 2015 at 03:01:54PM +0200, tomas.har...@codemill.se wrote: On 2015-03-30 14:21, Michael Niedermayer wrote: On Mon, Mar 30, 2015 at 12:31:04PM +0200, tomas.har...@codemill.se wrote: On 2015-03-30 12:19, tim nicholson wrote: Some software mis decodes IMX material in mxf if this metadata field is missing. See the discussion on the ffmpeg ML:- [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding? This patch add this field to mxf wrapped material. Looks fine, but I know from experience that all this stuff gets tricky quickly. Like there should be mechanisms in lavf for dealing with presentation rectangles and all that jazz, including different aspect ratios at different layers. should i apply this patch or wait ? Apply it - dealing with this properly (like for properly remuxing MOV -- MXF) would require quite a bit of design that shouldn't hold up this patch. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata
On 2015-03-30 14:21, Michael Niedermayer wrote: On Mon, Mar 30, 2015 at 12:31:04PM +0200, tomas.har...@codemill.se wrote: On 2015-03-30 12:19, tim nicholson wrote: Some software mis decodes IMX material in mxf if this metadata field is missing. See the discussion on the ffmpeg ML:- [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding? This patch add this field to mxf wrapped material. Looks fine, but I know from experience that all this stuff gets tricky quickly. Like there should be mechanisms in lavf for dealing with presentation rectangles and all that jazz, including different aspect ratios at different layers. should i apply this patch or wait ? Apply it - dealing with this properly (like for properly remuxing MOV -- MXF) would require quite a bit of design that shouldn't hold up this patch. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/03/15 13:21, Michael Niedermayer wrote: On Mon, Mar 30, 2015 at 12:31:04PM +0200, tomas.har...@codemill.se wro te: On 2015-03-30 12:19, tim nicholson wrote: Some software mis decodes IMX material in mxf if this metadata field is missing. See the discussion on the ffmpeg ML:- [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding? This patch add this field to mxf wrapped material. Looks fine, but I know from experience that all this stuff gets tricky quickly. Like there should be mechanisms in lavf for dealing with presentation rectangles and all that jazz, including different aspect ratios at different layers. should i apply this patch or wait ? Apply, as per IRC comments.. [...] - -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVGUmLAAoJEAwL/ESLC/yDmY0H/06658q5T2xtRpu2SRDlyLAY GVLbxpnlWu6s4ss4uB3GRmuGvlZuj2SmJxsvn4s7lKDRiEQIByw2FWIuws5y8CMQ +KhN9nXD2V5D+bHIBTeodb4vfFwLtA33ImPqrpnRawjvQi+b+Bm8Y1qUP1pRxEDF yKOVH1nG2ynNHBbzZgxNAhboGk2nIBHO9JRyMeGSR8XMCiQlsiXPvZcgLXVQ0htR e8DORhEHyNBKX6X6TxJlbqMwakPb+p9SfMXkjKdgzsrWyjz76gHqesDhgnhGwJ8S ApM+ja8Xiy3Q9npNmPxu2RpduDXJ6pJgt87rSn9ZVBs/c2SaT7/pROLL/Pj33T4= =VFpd -END PGP SIGNATURE- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
On Mon, Mar 30, 2015 at 11:37:10AM +0200, Wiebe Cazemier wrote: - Original Message - From: Kieran Kunhya kier...@obe.tv To: Wiebe Cazemier wi...@halfgaar.net Sent: Monday, 30 March, 2015 10:47:49 AM Subject: Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default It is not an option and I quote ETSI 102 366: Therefore, the AC-3 decoder shall, by default, implement the compression characteristic indicated by the dynrng values in the data stream. AC-3 decoders may optionally allow listener control over the use of the dynrng values, so that the listener may select full or partial dynamic range reproduction. If an application doesn't want to expose drc settings then that's their problem. FFmpeg does the right thing and lets you turn it off if you wish. Kieran (can you reply-all, so that your reply goes to the list?) If you say it's not an option, that's putting it harder than the spec say. Dolby engineers never meant AC3 audio to be played compressed everywhere, and that's what we're seeing happening. Also, I feel that the word 'decoder' in your quote is written in a time where it had a different context and that quote has to be interpreted that way. Open source software libraries weren't available at that point, and a decoder was a piece of hardware, or a chip embedded in something. Sure, you don't have to allow the user to control it when you embed an AC3 decoder in your budget TV so ATSC demanding that you do would be silly here, but all high end receivers I know, do allow you to set the option. Now that we do have a library that people can use, an honest mistake to forget to implement it turns into something that they probably didn't intend. As proven by the Kodi developer denying that they applied DRC. I think we have to consider user experience, and it's great when they can control it, but we're getting the situation where everybody gets it (yet only for AC3), whether they want to or not. That automatically crosses off Kodi and VLC (for example) for use in high quality sound reproduction. And the bad thing is, they may not even know it... It's the complete opposite - most people are watching on laptop speakers without the dynamic range you have in your setup. FFmpeg lets you turn it off and it's the fault of the player for not exposing that. What about those people playing AAC, which is the majority currently. In any case, I made my point. How do we proceed? I have no idea who is in charge of what, and how the decision making process goes in ffmpeg development. Generally decissions are made based on consensus or absence of objections. If that doesnt work there should be a maintainer for the specific part of the code. Iam not sure AC3 in FFmpeg does have a maintainer, justin is listed in MAINTAINERs but iam not sure if justin still (wants) to maintain ac3 in FFmpeg. so considering that kierank and andy seem to object to this patch someone should 1. ask justin if he is still MAINTAINING AC3 in FFmpeg 2a. if yes, ask him what to do 2b. if no send a patch to update the MAINTAINERs file and if noone else wants to maintain AC3 the decission would proably fall onto me, unless theres something resembling a consensus by then also independant of this, its probably a good idea if we make our users more aware of the drc_scale option. A news entry and or some mention in the next release notes is probably a good idea patches in that direction are welcome Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/8] png: Don't fail when a packet is larger than INT_MAX
On 30 March 2015 at 02:48, Michael Niedermayer michae...@gmx.at wrote: On Sun, Mar 29, 2015 at 11:05:41AM +, Donny Yang wrote: Signed-off-by: Donny Yang w...@kota.moe --- libavcodec/pngenc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c index 3697dbb..bd3aae5 100644 --- a/libavcodec/pngenc.c +++ b/libavcodec/pngenc.c @@ -373,8 +373,6 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, enc_row_size + 12 * (((int64_t)enc_row_size + IOBUF_SIZE - 1) / IOBUF_SIZE) // 12 * ceil(enc_row_size / IOBUF_SIZE) ); -if (max_packet_size INT_MAX) -return AVERROR(ENOMEM); the check is neccessary to prevent potential integer overflows Doesn't ffmpeg support memory allocations of greater than 4 GiB? I thought it did because the memory allocation functions either accept an int64_t or size_t... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
2015-03-30 12:10 GMT+02:00 Kieran Kunhya kier...@obe.tv: We should have DRC enabled in AAC and other codecs if it's considered a normative part of the spec. So basically you do what the spec says regardless of whether it makes sense or not? Best regards, Mathias. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata
On 2015-03-30 12:19, tim nicholson wrote: Some software mis decodes IMX material in mxf if this metadata field is missing. See the discussion on the ffmpeg ML:- [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding? This patch add this field to mxf wrapped material. Looks fine, but I know from experience that all this stuff gets tricky quickly. Like there should be mechanisms in lavf for dealing with presentation rectangles and all that jazz, including different aspect ratios at different layers. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
On 30 March 2015 at 11:24, madshi mad...@gmail.com wrote: 2015-03-30 12:10 GMT+02:00 Kieran Kunhya kier...@obe.tv: We should have DRC enabled in AAC and other codecs if it's considered a normative part of the spec. So basically you do what the spec says regardless of whether it makes sense or not? Yes, and we let power users change things from the API - I don't see why that's so hard. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
2015-03-30 12:28 GMT+02:00 Kieran Kunhya kier...@obe.tv: Yes, and we let power users change things from the API - I don't see why that's so hard. It's not hard. The only problem is that there are many many applications out there using ffmpeg, and many (most?) of them are not aware of drc_scale. So they decode AC3 with subpar quality. And there's nothing the *end user* can do about it. Most end users are not aware of the problem, so they get subpar quality without even knowing it. Sure, you can blame the applications for not setting drc_scale. I blame ffmpeg instead, for outputting subpar quality *by default*. Best regards, Mathias. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata
On 30/03/15 11:31, tomas.har...@codemill.se wrote: On 2015-03-30 12:19, tim nicholson wrote: Some software mis decodes IMX material in mxf if this metadata field is missing. See the discussion on the ffmpeg ML:- [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding? This patch add this field to mxf wrapped material. Looks fine, but I know from experience that all this stuff gets tricky quickly. Like there should be mechanisms in lavf for dealing with presentation rectangles and all that jazz, including different aspect ratios at different layers. Well I thought about adding the X offset too for completeness, but currently due to the lack of the above mechanisms there didn't seem much point as there was nothing to set it from.. (one use would be the 720/702 blanking which some systems also want, but I can see no current programmatical way of setting it.) /Tomas [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata
On Mon, Mar 30, 2015 at 12:31:04PM +0200, tomas.har...@codemill.se wrote: On 2015-03-30 12:19, tim nicholson wrote: Some software mis decodes IMX material in mxf if this metadata field is missing. See the discussion on the ffmpeg ML:- [FFmpeg-user] How to set 3 specific metadata flags (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding? This patch add this field to mxf wrapped material. Looks fine, but I know from experience that all this stuff gets tricky quickly. Like there should be mechanisms in lavf for dealing with presentation rectangles and all that jazz, including different aspect ratios at different layers. should i apply this patch or wait ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
Le decadi 10 germinal, an CCXXIII, madshi a écrit : What do you think would happen if we started a vote like the following: 1) Should ffmpeg output reduced (range compressed) audio quality by default, because the spec says so? 2) Should ffmpeg output full (range) quality by default, unless the software asks ffmpeg to do otherwise? How many users or devs would vote for 1) or 2)? Kieran will answer you the spec is right even if it tells you that 2+2=5. ;-) My answer is: profile, don't speculate. Q: the user has quality audio equipment that can play full range K: the user knows that there is an option D: quantified damage to the sound (subjective impression translated to an approximate value) d1: quantified damage of playing compressed range on quality equipment d2: quantified damage of playing full range on poor equipment d3: quantified damage of having to set an option E(D) = P(K)×d3 + P(¬K∧Q)×d1 if compression is the default E(D) = P(K)×d3 + P(¬K∧¬Q)×d2 is compression is disabled by default. So basically, you need to provide convincing estimates for the ratio between P(¬K∧Q) and P(¬K∧¬Q) and the one between d1 and d2. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/8] png: Don't fail when a packet is larger than INT_MAX
On Mon, 30 Mar 2015 13:49:08 + Donny Yang w...@kota.moe wrote: On 30 March 2015 at 02:48, Michael Niedermayer michae...@gmx.at wrote: On Sun, Mar 29, 2015 at 11:05:41AM +, Donny Yang wrote: Signed-off-by: Donny Yang w...@kota.moe --- libavcodec/pngenc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c index 3697dbb..bd3aae5 100644 --- a/libavcodec/pngenc.c +++ b/libavcodec/pngenc.c @@ -373,8 +373,6 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, enc_row_size + 12 * (((int64_t)enc_row_size + IOBUF_SIZE - 1) / IOBUF_SIZE) // 12 * ceil(enc_row_size / IOBUF_SIZE) ); -if (max_packet_size INT_MAX) -return AVERROR(ENOMEM); the check is neccessary to prevent potential integer overflows Doesn't ffmpeg support memory allocations of greater than 4 GiB? I thought it did because the memory allocation functions either accept an int64_t or size_t... No. The codebase is so rotten, libavutil/mem.c even limits memory allocations to INT_MAX. In your specific case the problem is that AVPacket.size is an int. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Proof-of-concept HTTP Server
Le nonidi 9 germinal, an CCXXIII, Stephan Holljes a écrit : I hope this addresses the issues mentioned. I added a new label in case of failure in http_open() in favor of duplicated code (i.e. calling av_dict_free() multiple times). I copied the style from the other functions. Signed-off-by: Stephan Holljes klaxa1...@googlemail.com The patch looks good to me (acronym to learn: LGTM) as is or with the code moved into a separate function point. Except one more point that was not addressed earlier: if you want to add comments to a Git patch email, you need to put them between the --- and the first diff --git lines. That is where the small stats 2 files changed, 28 insertions(+), 1 deletion(-) is already inserted, it is considered as a simple comment too. If you put them before the --- line, it becomes part of the commit message when the patch is applied from the mail. For the final version, maybe better attach the patch or push it to a public clone. At this point, I suspect you can consider this will be applied soon (better give it maybe two days before asking for merging) and, if you want to strengthen your application, make the patch even better, for example getting it to work for input as well as output. For that, I suspect it will be convenient for you to isolate the code in its own function, that makes handling the variables and the failure code path easier, so you probably better follow wm4's advice. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/8] png: Don't fail when a packet is larger than INT_MAX
On Mon, Mar 30, 2015 at 05:11:05PM +0200, wm4 wrote: On Mon, 30 Mar 2015 13:49:08 + Donny Yang w...@kota.moe wrote: On 30 March 2015 at 02:48, Michael Niedermayer michae...@gmx.at wrote: On Sun, Mar 29, 2015 at 11:05:41AM +, Donny Yang wrote: Signed-off-by: Donny Yang w...@kota.moe --- libavcodec/pngenc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c index 3697dbb..bd3aae5 100644 --- a/libavcodec/pngenc.c +++ b/libavcodec/pngenc.c @@ -373,8 +373,6 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, enc_row_size + 12 * (((int64_t)enc_row_size + IOBUF_SIZE - 1) / IOBUF_SIZE) // 12 * ceil(enc_row_size / IOBUF_SIZE) ); -if (max_packet_size INT_MAX) -return AVERROR(ENOMEM); the check is neccessary to prevent potential integer overflows Doesn't ffmpeg support memory allocations of greater than 4 GiB? I thought it did because the memory allocation functions either accept an int64_t or size_t... No. That is false, the maximum allocation size is set by av_max_alloc() its INT_MAX by default but can be increased. The reason for it being INT_MAX by default is that it limits broken media streams from allocating insane amounts of memory and by limiting below the 32bit range it protects against integer overflows in places that use int to store a size or index The codebase is so rotten, The mailing lists and IRC channels exist to foster the development and use of FFmpeg. Non-constructive or off-topic messages, along with other abuses, are not welcome. libavutil/mem.c even limits memory allocations to INT_MAX. this is misleading, it limits to a user settable variable that has a default of INT_MAX In your specific case the problem is that AVPacket.size is an int. yes and no. yes, AVPacket.size could be changed to int64_t, that would need major ABI version and soname bumps of all libs though. Its something that could be done during the next such bump. but that is missing a point, AVPackets of 4GiB are very unwieldy and would be very akward to handle in applications If we do add support for frames larger than 4gb samples, then maybe a different system than storing all of it in a single array in memory should be considered. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
Himangi Saraogi himangi774 at gmail.com writes: case TIFF_LZW: return ff_lzw_encode(s-lzws, src, n); default: -return -1; +return AVERROR(EINVAL); Please print a message in this case or explain why this is not a good idea. (And please don't make me write this a fourth time, thank you.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
---
libavcodec/tiffenc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavcodec/tiffenc.c b/libavcodec/tiffenc.c
index 44cd956..2cdac0b 100644
--- a/libavcodec/tiffenc.c
+++ b/libavcodec/tiffenc.c
@@ -164,7 +164,8 @@ static int add_entry1(TiffEncoderContext *s,
* @param dst output buffer
* @param n size of input buffer
* @param compr compression method
- * @return number of output bytes. If an output error is encountered, -1 is
returned
+ * @return number of output bytes. If an output error is encountered, a
negative
+ * value corresponding to an AVERROR error code is returned.
*/
static int encode_strip(TiffEncoderContext *s, const int8_t *src,
uint8_t *dst, int n, int compr)
@@ -177,14 +178,14 @@ static int encode_strip(TiffEncoderContext *s, const
int8_t *src,
unsigned long zlen = s-buf_size - (*s-buf - s-buf_start);
if (compress(dst, zlen, src, n) != Z_OK) {
av_log(s-avctx, AV_LOG_ERROR, Compressing failed\n);
-return -1;
+return AVERROR_EXTERNAL;
}
return zlen;
}
#endif
case TIFF_RAW:
if (check_size(s, n))
-return -1;
+return AVERROR(EINVAL);
memcpy(dst, src, n);
return n;
case TIFF_PACKBITS:
@@ -193,7 +194,9 @@ static int encode_strip(TiffEncoderContext *s, const int8_t
*src,
case TIFF_LZW:
return ff_lzw_encode(s-lzws, src, n);
default:
-return -1;
+av_log(s-avctx, AV_LOG_ERROR, Unsupported compression method: %d\n,
+ compr);
+return AVERROR(EINVAL);
}
}
@@ -304,7 +307,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
default:
av_log(s-avctx, AV_LOG_ERROR,
This colors format is not supported\n);
-return -1;
+return AVERROR(EINVAL);
}
for (i = 0; i s-bpp_tab_size; i++)
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
On Mon, Mar 30, 2015 at 10:24:06PM +0530, Himangi Saraogi wrote: --- libavcodec/tiffenc.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/8] png: Don't fail when a packet is larger than INT_MAX
On Mon, Mar 30, 2015 at 06:02:35PM +0200, wm4 wrote: On Mon, 30 Mar 2015 17:47:03 +0200 Michael Niedermayer michae...@gmx.at wrote: On Mon, Mar 30, 2015 at 05:11:05PM +0200, wm4 wrote: On Mon, 30 Mar 2015 13:49:08 + Donny Yang w...@kota.moe wrote: On 30 March 2015 at 02:48, Michael Niedermayer michae...@gmx.at wrote: On Sun, Mar 29, 2015 at 11:05:41AM +, Donny Yang wrote: Signed-off-by: Donny Yang w...@kota.moe --- libavcodec/pngenc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c index 3697dbb..bd3aae5 100644 --- a/libavcodec/pngenc.c +++ b/libavcodec/pngenc.c @@ -373,8 +373,6 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, enc_row_size + 12 * (((int64_t)enc_row_size + IOBUF_SIZE - 1) / IOBUF_SIZE) // 12 * ceil(enc_row_size / IOBUF_SIZE) ); -if (max_packet_size INT_MAX) -return AVERROR(ENOMEM); the check is neccessary to prevent potential integer overflows Doesn't ffmpeg support memory allocations of greater than 4 GiB? I thought it did because the memory allocation functions either accept an int64_t or size_t... No. That is false, the maximum allocation size is set by av_max_alloc() its INT_MAX by default but can be increased. This is a library-unsafe hack that shouldn't exist. Access isn't even synchronized, terrible. This thread is about a GSoC qualification task. this is getting quite off topic ... But if you have a patch that makes code which is per process suddenly work per library and isnt a ultra terrible mess iam sure interrested to see that patch. But i dont see how that can be done av_malloc() like malloc() have no context so theres no easy way to have per library limits [...] Is the dimension limit on ca. 16000x16000 images intentional too? (This actually prevents ffmpeg being used to read large images.) will you go over all open bugs in this thread? but like with any other bug, if you want to fix it do fix it. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
On 30 March 2015 at 22:00, Carl Eugen Hoyos ceho...@ag.or.at wrote: Himangi Saraogi himangi774 at gmail.com writes: case TIFF_LZW: return ff_lzw_encode(s-lzws, src, n); default: -return -1; +return AVERROR(EINVAL); Please print a message in this case or explain why this is not a good idea. (And please don't make me write this a fourth time, thank you.) Sure. Sorry to have missed that comment. -Himangi Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for High color and High bit-depth support
Debargha Mukherjee debargha at google.com writes:
- if (avctx-profile != FF_PROFILE_UNKNOWN)
- enccfg.g_profile = avctx-profile;
+if (avctx-profile != FF_PROFILE_UNKNOWN) {
+enccfg.g_profile = avctx-profile;
+}
Please make this a separate patch, do not mix
functional and cosmetic changes.
+#ifdef VPX_IMG_FMT_HIGHBITDEPTH
+.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV444P,
+#else
+.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV444P,
I don't think this is more readable than having
#ifdef VPX_IMG_FMT_HIGHBITDEPTH in the middle of
the list. Do you disagree?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_vignette: force per frame evaluation if per frame variables are used
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavfilter/vf_vignette.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_vignette.c b/libavfilter/vf_vignette.c
index 806bd72..9a05651 100644
--- a/libavfilter/vf_vignette.c
+++ b/libavfilter/vf_vignette.c
@@ -161,15 +161,20 @@ static void update_context(VignetteContext *s,
AVFilterLink *inlink, AVFrame *fr
s-var_values[VAR_T] = TS2T(frame-pts, inlink-time_base);
s-var_values[VAR_PTS] = TS2D(frame-pts);
} else {
-s-var_values[VAR_N] = 0;
+s-var_values[VAR_N] = NAN;
s-var_values[VAR_T] = NAN;
s-var_values[VAR_PTS] = NAN;
}
-s-angle = av_clipf(av_expr_eval(s-angle_pexpr, s-var_values, NULL), 0,
M_PI_2);
+s-angle = av_expr_eval(s-angle_pexpr, s-var_values, NULL);
s-x0 = av_expr_eval(s-x0_pexpr, s-var_values, NULL);
s-y0 = av_expr_eval(s-y0_pexpr, s-var_values, NULL);
+if (isnan(s-x0) || isnan(s-y0) || isnan(s-angle))
+s-eval_mode = EVAL_MODE_FRAME;
+
+s-angle = av_clipf(s-angle, 0, M_PI_2);
+
if (s-backward) {
for (y = 0; y inlink-h; y++) {
for (x = 0; x inlink-w; x++)
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: Add support for WebM Live Muxing
Vignesh Venkatasubramanian vigneshv at google.com writes:
+if (!wc-oformat) { return AVERROR_MUXER_NOT_FOUND; }
It is your file but most people here seem to agree
that the following is more (and not less) readable:
if (!wc-oformat)
return AVERROR_MUXER_NOT_FOUND;
+if ((ret = chunk_mux_init(s)) 0) { return ret; }
It is your decision but not merging assignment and
comparison is common practice here: I suspect both
for readability and because it saves a lot of time
debugging...
+oc-streams = NULL;
+oc-nb_streams = 0;
+avformat_free_context(oc);
+oc-streams = NULL;
+oc-nb_streams = 0;
+avformat_free_context(oc);
The first two seem unnecessary if you call
avformat_free_context().
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf: Add support for WebM Live Muxing
This patch adds support for WebM Live Muxing by adding a new WebM
Chunk muxer. It writes out live WebM Chunks which can be used for
playback using Live DASH Clients.
Please see muxers.texi for sample usage.
Signed-off-by: Vignesh Venkatasubramanian vigne...@google.com
---
Changelog | 1 +
doc/muxers.texi | 43
libavformat/Makefile | 5 +-
libavformat/allformats.c | 1 +
libavformat/matroskaenc.c | 12 ++-
libavformat/version.h | 2 +-
libavformat/webm_chunk.c | 251 ++
7 files changed, 309 insertions(+), 6 deletions(-)
create mode 100644 libavformat/webm_chunk.c
diff --git a/Changelog b/Changelog
index 75da156..2c7f283 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version next:
- Detelecine filter
- Intel QSV-accelerated H.264 encoding
- MMAL-accelerated H.264 decoding
+- WebM Live Chunk Muxer
version 2.6:
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a8225fc..d9d900b 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1236,4 +1236,47 @@ ffmpeg -f webm_dash_manifest -i video1.webm \
manifest.xml
@end example
+@section webm_chunk
+
+WebM Live Chunk Muxer.
+
+This muxer writes out WebM headers and chunks as separate files which can be
+consumed by clients that support WebM Live streams via DASH.
+
+@subsection Options
+
+This muxer supports the following options:
+
+@table @option
+@item chunk_start_index
+Index of the first chunk (defaults to 0).
+
+@item header
+Filename of the header where the initialization data will be written.
+
+@item audio_chunk_duration
+Duration of each audio chunk in milliseconds (defaults to 5000).
+@end table
+
+@subsection Example
+@example
+ffmpeg -f v4l2 -i /dev/video0 \
+ -f alsa -i hw:0 \
+ -map 0:0 \
+ -c:v libvpx-vp9 \
+ -s 640x360 -keyint_min 30 -g 30 \
+ -f webm_chunk \
+ -header webm_live_video_360.hdr \
+ -chunk_start_index 1 \
+ webm_live_video_360_%d.chk \
+ -map 1:0 \
+ -c:a libvorbis \
+ -b:a 128k \
+ -f webm_chunk \
+ -header webm_live_audio_128.hdr \
+ -chunk_start_index 1 \
+ -audio_chunk_duration 1000 \
+ webm_live_audio_128_%d.chk
+@end example
+
@c man end MUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2118ff2..e40ed4d 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -237,7 +237,7 @@ OBJS-$(CONFIG_MATROSKA_DEMUXER) += matroskadec.o
matroska.o \
OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o matroska.o \
isom.o avc.o hevc.o \
flacenc_header.o avlanguage.o
vorbiscomment.o wv.o \
-webmdashenc.o
+webmdashenc.o webm_chunk.o
OBJS-$(CONFIG_MD5_MUXER) += md5enc.o
OBJS-$(CONFIG_MGSTS_DEMUXER) += mgsts.o
OBJS-$(CONFIG_MICRODVD_DEMUXER) += microdvddec.o subtitles.o
@@ -451,12 +451,13 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
isom.o avc.o hevc.o \
flacenc_header.o avlanguage.o \
wv.o vorbiscomment.o \
-webmdashenc.o
+webmdashenc.o webm_chunk.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER)+= matroskadec.o matroska.o \
isom.o rmsipr.o flac_picture.o \
oggparsevorbis.o vorbiscomment.o \
flac_picture.o replaygain.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o matroska.o
+OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o matroska.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 26ccc27..f56493c 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -316,6 +316,7 @@ void av_register_all(void)
REGISTER_DEMUXER (WC3, wc3);
REGISTER_MUXER (WEBM, webm);
REGISTER_MUXDEMUX(WEBM_DASH_MANIFEST, webm_dash_manifest);
+REGISTER_MUXER (WEBM_CHUNK, webm_chunk);
REGISTER_MUXER (WEBP, webp);
REGISTER_MUXDEMUX(WEBVTT, webvtt);
REGISTER_DEMUXER (WSAUD,wsaud);
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 6b2e390..027605e 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -120,6 +120,7 @@ typedef struct MatroskaMuxContext {
int64_t cluster_time_limit;
int is_dash;
int dash_track_number;
+
[FFmpeg-devel] Ticket 4386 : crash create by previous patch
Hello, After some research, the crash when reading exr Piz file (ticket 4386), appear with this patch : https://github.com/FFmpeg/FFmpeg/commit/586ba24ff29468d2a4ee843a9650feea5b2be6f6 if, i use the previous line : memset(lut + k, 0, (USHORT_RANGE - k) * 2); instead of the new one : memset(lut + k * 2, 0, (USHORT_RANGE - k) * 2); crash disappear. But i suppose, this previous patch have been made for a reason... Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: Add support for WebM Live Muxing
Vignesh Venkatasubramanian vigneshv at google.com writes: +oc-streams = NULL; +oc-nb_streams = 0; +avformat_free_context(oc); The first two seem unnecessary if you call avformat_free_context(). The first two lines are intentional. Sorry about the comment;-) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libdcadec: remove av_assert and check bits_per_sample more completely
On Sun, Mar 29, 2015 at 01:19:11PM +0200, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavcodec/libdcadec.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vf_drawtext: add support for setting box border width
Signed-off-by: Marton Balint c...@passwd.hu
---
doc/filters.texi | 4
libavfilter/vf_drawtext.c | 5 -
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 15f8ed5..b75ce5a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3955,6 +3955,10 @@ Used to draw a box around text using the background
color.
The value must be either 1 (enable) or 0 (disable).
The default value of @var{box} is 0.
+@item boxborderw
+Set the width of the border to be drawn around the box using @var{boxcolor}.
+The default value of @var{boxborderw} is 0.
+
@item boxcolor
The color to be used for drawing box around text. For the syntax of this
option, check the Color section in the ffmpeg-utils manual.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index cf24d96..a955d09 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -159,6 +159,7 @@ typedef struct DrawTextContext {
unsigned int fontsize; /// font size to use
short int draw_box; /// draw box around text - true or false
+int boxborderw; /// box border width
int use_kerning;/// font kerning is used - true/false
int tabsize;/// tab size
int fix_bounds; /// do we let it go out of frame bounds -
t/f
@@ -204,6 +205,7 @@ static const AVOption drawtext_options[]= {
{bordercolor, set border color, OFFSET(bordercolor.rgba),
AV_OPT_TYPE_COLOR, {.str=black}, CHAR_MIN, CHAR_MAX, FLAGS},
{shadowcolor, set shadow color, OFFSET(shadowcolor.rgba),
AV_OPT_TYPE_COLOR, {.str=black}, CHAR_MIN, CHAR_MAX, FLAGS},
{box, set box, OFFSET(draw_box),
AV_OPT_TYPE_INT,{.i64=0}, 0,1 , FLAGS},
+{boxborderw, set box border width, OFFSET(boxborderw),
AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX , FLAGS},
{fontsize,set font size,OFFSET(fontsize),
AV_OPT_TYPE_INT,{.i64=0}, 0,INT_MAX , FLAGS},
{x, set x expression, OFFSET(x_expr),
AV_OPT_TYPE_STRING, {.str=0}, CHAR_MIN, CHAR_MAX, FLAGS},
{y, set y expression, OFFSET(y_expr),
AV_OPT_TYPE_STRING, {.str=0}, CHAR_MIN, CHAR_MAX, FLAGS},
@@ -1245,7 +1247,8 @@ static int draw_text(AVFilterContext *ctx, AVFrame *frame,
if (s-draw_box)
ff_blend_rectangle(s-dc, s-boxcolor,
frame-data, frame-linesize, width, height,
- s-x, s-y, box_w, box_h);
+ s-x - s-boxborderw, s-y - s-boxborderw,
+ box_w + s-boxborderw * 2, box_h + s-boxborderw *
2);
if (s-shadowx || s-shadowy) {
if ((ret = draw_glyphs(s, frame, width, height,
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: Add support for WebM Live Muxing
On Mon, 30 Mar 2015 12:49:45 -0700 Vignesh Venkatasubramanian vigne...@google.com wrote: This patch adds support for WebM Live Muxing by adding a new WebM Chunk muxer. It writes out live WebM Chunks which can be used for playback using Live DASH Clients. Please see muxers.texi for sample usage. Signed-off-by: Vignesh Venkatasubramanian vigne...@google.com --- Changelog | 1 + doc/muxers.texi | 43 libavformat/Makefile | 5 +- libavformat/allformats.c | 1 + libavformat/matroskaenc.c | 12 ++- libavformat/version.h | 2 +- libavformat/webm_chunk.c | 251 ++ 7 files changed, 309 insertions(+), 6 deletions(-) create mode 100644 libavformat/webm_chunk.c diff --git a/Changelog b/Changelog index 75da156..2c7f283 100644 --- a/Changelog +++ b/Changelog @@ -12,6 +12,7 @@ version next: - Detelecine filter - Intel QSV-accelerated H.264 encoding - MMAL-accelerated H.264 decoding +- WebM Live Chunk Muxer version 2.6: diff --git a/doc/muxers.texi b/doc/muxers.texi index a8225fc..d9d900b 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -1236,4 +1236,47 @@ ffmpeg -f webm_dash_manifest -i video1.webm \ manifest.xml @end example +@section webm_chunk + +WebM Live Chunk Muxer. + +This muxer writes out WebM headers and chunks as separate files which can be +consumed by clients that support WebM Live streams via DASH. + +@subsection Options + +This muxer supports the following options: + +@table @option +@item chunk_start_index +Index of the first chunk (defaults to 0). + +@item header +Filename of the header where the initialization data will be written. + +@item audio_chunk_duration +Duration of each audio chunk in milliseconds (defaults to 5000). +@end table + +@subsection Example +@example +ffmpeg -f v4l2 -i /dev/video0 \ + -f alsa -i hw:0 \ + -map 0:0 \ + -c:v libvpx-vp9 \ + -s 640x360 -keyint_min 30 -g 30 \ + -f webm_chunk \ + -header webm_live_video_360.hdr \ + -chunk_start_index 1 \ + webm_live_video_360_%d.chk \ + -map 1:0 \ + -c:a libvorbis \ + -b:a 128k \ + -f webm_chunk \ + -header webm_live_audio_128.hdr \ + -chunk_start_index 1 \ + -audio_chunk_duration 1000 \ + webm_live_audio_128_%d.chk +@end example + @c man end MUXERS diff --git a/libavformat/Makefile b/libavformat/Makefile index 2118ff2..e40ed4d 100644 --- a/libavformat/Makefile +++ b/libavformat/Makefile @@ -237,7 +237,7 @@ OBJS-$(CONFIG_MATROSKA_DEMUXER) += matroskadec.o matroska.o \ OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o matroska.o \ isom.o avc.o hevc.o \ flacenc_header.o avlanguage.o vorbiscomment.o wv.o \ -webmdashenc.o +webmdashenc.o webm_chunk.o OBJS-$(CONFIG_MD5_MUXER) += md5enc.o OBJS-$(CONFIG_MGSTS_DEMUXER) += mgsts.o OBJS-$(CONFIG_MICRODVD_DEMUXER) += microdvddec.o subtitles.o @@ -451,12 +451,13 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o matroska.o \ isom.o avc.o hevc.o \ flacenc_header.o avlanguage.o \ wv.o vorbiscomment.o \ -webmdashenc.o +webmdashenc.o webm_chunk.o OBJS-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER)+= matroskadec.o matroska.o \ isom.o rmsipr.o flac_picture.o \ oggparsevorbis.o vorbiscomment.o \ flac_picture.o replaygain.o OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o matroska.o +OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o matroska.o OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o diff --git a/libavformat/allformats.c b/libavformat/allformats.c index 26ccc27..f56493c 100644 --- a/libavformat/allformats.c +++ b/libavformat/allformats.c @@ -316,6 +316,7 @@ void av_register_all(void) REGISTER_DEMUXER (WC3, wc3); REGISTER_MUXER (WEBM, webm); REGISTER_MUXDEMUX(WEBM_DASH_MANIFEST, webm_dash_manifest); +REGISTER_MUXER (WEBM_CHUNK, webm_chunk); REGISTER_MUXER (WEBP, webp); REGISTER_MUXDEMUX(WEBVTT, webvtt); REGISTER_DEMUXER (WSAUD,wsaud); diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index
Re: [FFmpeg-devel] [PATCH 1/4] lavf: add directory listing API
On 30.03.2015 03:01, Michael Niedermayer wrote: On Mon, Mar 30, 2015 at 12:36:34AM +0200, Lukasz Marek wrote: On 29.03.2015 01:14, Mariusz Szczepańczyk wrote: diff --git a/doc/APIchanges b/doc/APIchanges index 3f153e9..814f752 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,15 @@ libavutil: 2014-08-09 API changes, most recent first: +2015-03-27 - 184084c - lavf 56.27.100 - avio.h url.h + New directory listing API. + + Add AVIODirEntryType enum. + Add AVIODirEntry, AVIODirContext structures. + Add avio_open_dir(), avio_read_dir(), avio_close_dir(), avio_free_directory_entry(). + Add ff_alloc_dir_entry(). + Extend URLProtocol with url_open_dir(), url_read_dir(), url_close_dir(). It can be simple add url_open_dir()..., but it is OK I think + 8 - FFmpeg 2.6 was cut here 8 - 2015-03-04 - cca4476 - lavf 56.25.100 diff --git a/libavformat/version.h b/libavformat/version.h index a183d7f..ff85227 100644 --- a/libavformat/version.h +++ b/libavformat/version.h @@ -30,7 +30,7 @@ #include libavutil/version.h #define LIBAVFORMAT_VERSION_MAJOR 56 -#define LIBAVFORMAT_VERSION_MINOR 26 +#define LIBAVFORMAT_VERSION_MINOR 27 Michaels, do you gonna merge it? this one still had a minor issue in the version number but if the next looks fine to you or you want to correct it yourself dont hesitate to apply it Fixed locally and pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf: Add support for WebM Live Muxing
This patch adds support for WebM Live Muxing by adding a new WebM
Chunk muxer. It writes out live WebM Chunks which can be used for
playback using Live DASH Clients.
Please see muxers.texi for sample usage.
Signed-off-by: Vignesh Venkatasubramanian vigne...@google.com
---
Changelog | 1 +
doc/muxers.texi | 43
libavformat/Makefile | 5 +-
libavformat/allformats.c | 1 +
libavformat/matroskaenc.c | 12 ++-
libavformat/version.h | 2 +-
libavformat/webm_chunk.c | 262 ++
7 files changed, 320 insertions(+), 6 deletions(-)
create mode 100644 libavformat/webm_chunk.c
diff --git a/Changelog b/Changelog
index 75da156..2c7f283 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version next:
- Detelecine filter
- Intel QSV-accelerated H.264 encoding
- MMAL-accelerated H.264 decoding
+- WebM Live Chunk Muxer
version 2.6:
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a8225fc..d9d900b 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1236,4 +1236,47 @@ ffmpeg -f webm_dash_manifest -i video1.webm \
manifest.xml
@end example
+@section webm_chunk
+
+WebM Live Chunk Muxer.
+
+This muxer writes out WebM headers and chunks as separate files which can be
+consumed by clients that support WebM Live streams via DASH.
+
+@subsection Options
+
+This muxer supports the following options:
+
+@table @option
+@item chunk_start_index
+Index of the first chunk (defaults to 0).
+
+@item header
+Filename of the header where the initialization data will be written.
+
+@item audio_chunk_duration
+Duration of each audio chunk in milliseconds (defaults to 5000).
+@end table
+
+@subsection Example
+@example
+ffmpeg -f v4l2 -i /dev/video0 \
+ -f alsa -i hw:0 \
+ -map 0:0 \
+ -c:v libvpx-vp9 \
+ -s 640x360 -keyint_min 30 -g 30 \
+ -f webm_chunk \
+ -header webm_live_video_360.hdr \
+ -chunk_start_index 1 \
+ webm_live_video_360_%d.chk \
+ -map 1:0 \
+ -c:a libvorbis \
+ -b:a 128k \
+ -f webm_chunk \
+ -header webm_live_audio_128.hdr \
+ -chunk_start_index 1 \
+ -audio_chunk_duration 1000 \
+ webm_live_audio_128_%d.chk
+@end example
+
@c man end MUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2118ff2..e40ed4d 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -237,7 +237,7 @@ OBJS-$(CONFIG_MATROSKA_DEMUXER) += matroskadec.o
matroska.o \
OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o matroska.o \
isom.o avc.o hevc.o \
flacenc_header.o avlanguage.o
vorbiscomment.o wv.o \
-webmdashenc.o
+webmdashenc.o webm_chunk.o
OBJS-$(CONFIG_MD5_MUXER) += md5enc.o
OBJS-$(CONFIG_MGSTS_DEMUXER) += mgsts.o
OBJS-$(CONFIG_MICRODVD_DEMUXER) += microdvddec.o subtitles.o
@@ -451,12 +451,13 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
isom.o avc.o hevc.o \
flacenc_header.o avlanguage.o \
wv.o vorbiscomment.o \
-webmdashenc.o
+webmdashenc.o webm_chunk.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER)+= matroskadec.o matroska.o \
isom.o rmsipr.o flac_picture.o \
oggparsevorbis.o vorbiscomment.o \
flac_picture.o replaygain.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o matroska.o
+OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o matroska.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 26ccc27..f56493c 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -316,6 +316,7 @@ void av_register_all(void)
REGISTER_DEMUXER (WC3, wc3);
REGISTER_MUXER (WEBM, webm);
REGISTER_MUXDEMUX(WEBM_DASH_MANIFEST, webm_dash_manifest);
+REGISTER_MUXER (WEBM_CHUNK, webm_chunk);
REGISTER_MUXER (WEBP, webp);
REGISTER_MUXDEMUX(WEBVTT, webvtt);
REGISTER_DEMUXER (WSAUD,wsaud);
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 6b2e390..027605e 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -120,6 +120,7 @@ typedef struct MatroskaMuxContext {
int64_t cluster_time_limit;
int is_dash;
int dash_track_number;
+
Re: [FFmpeg-devel] [PATCH] lavf: Add support for WebM Live Muxing
When are we going to get a DASH demuxer? Why don't you implement it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavf/segment: style nits
---
libavformat/segment.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 7b8fdad..69038ca 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -226,7 +226,7 @@ static int segment_start(AVFormatContext *s, int
write_header)
}
seg-segment_idx++;
-if ((seg-segment_idx_wrap) (seg-segment_idx%seg-segment_idx_wrap ==
0))
+if ((seg-segment_idx_wrap) (seg-segment_idx % seg-segment_idx_wrap
== 0))
seg-segment_idx_wrap_nb++;
if ((err = set_segment_filename(s)) 0)
@@ -761,7 +761,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
int64_t avgt = av_gettime();
time_t sec = avgt / 100;
localtime_r(sec, ti);
-usecs = (int64_t)(ti.tm_hour*3600 + ti.tm_min*60 + ti.tm_sec) *
100 + (avgt % 100);
+usecs = (int64_t)(ti.tm_hour * 3600 + ti.tm_min * 60 + ti.tm_sec)
* 100 + (avgt % 100);
wrapped_val = usecs % seg-time;
if (seg-last_cut != usecs wrapped_val seg-last_val) {
seg-cut_pending = 1;
@@ -769,7 +769,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
}
seg-last_val = wrapped_val;
} else {
-end_pts = seg-time * (seg-segment_count+1);
+end_pts = seg-time * (seg-segment_count + 1);
}
}
@@ -797,7 +797,7 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
goto fail;
seg-cut_pending = 0;
-seg-cur_entry.index = seg-segment_idx +
seg-segment_idx_wrap*seg-segment_idx_wrap_nb;
+seg-cur_entry.index = seg-segment_idx + seg-segment_idx_wrap *
seg-segment_idx_wrap_nb;
seg-cur_entry.start_time = (double)pkt-pts * av_q2d(st-time_base);
seg-cur_entry.start_pts = av_rescale_q(pkt-pts, st-time_base,
AV_TIME_BASE_Q);
seg-cur_entry.end_time = seg-cur_entry.start_time +
--
2.3.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] WIP: lavf/segment: provide a virtual AVIOContext representing all the segments
This needs a fair bit of testing and review before merge.
---
libavformat/segment.c | 259 ++
1 file changed, 198 insertions(+), 61 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 69038ca..4d934a2 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -48,8 +48,10 @@ typedef struct SegmentListEntry {
int64_t start_pts;
int64_t offset_pts;
char *filename;
+char *full_filename;
struct SegmentListEntry *next;
int64_t last_duration;
+size_t start_offset;
} SegmentListEntry;
typedef enum {
@@ -114,7 +116,13 @@ typedef struct SegmentContext {
SegmentListEntry cur_entry;
SegmentListEntry *segment_list_entries;
+SegmentListEntry *segment_list_entries_all;
SegmentListEntry *segment_list_entries_end;
+SegmentListEntry *segment_list_entry_writing;
+int seekback; /// allow seeking back to previous segments
+AVIOContext *cur_pb; /// current segment put-byte context
+size_t write_offset;
+size_t max_offset;
} SegmentContext;
static void print_csv_escaped_str(AVIOContext *ctx, const char *str)
@@ -133,6 +141,122 @@ static void print_csv_escaped_str(AVIOContext *ctx, const
char *str)
avio_w8(ctx, '');
}
+static int64_t virtual_seek(void *priv, int64_t target, int whence)
+{
+AVFormatContext *s = priv;
+SegmentContext *seg = s-priv_data;
+SegmentListEntry *it, *current = NULL;
+int64_t offset = target;
+int64_t ret;
+
+if (whence != SEEK_SET)
+return AVERROR(EINVAL);
+if (offset 0)
+return AVERROR(EINVAL);
+
+if (offset = seg-max_offset) {
+avio_closep(seg-cur_pb);
+seg-write_offset = offset;
+return offset;
+}
+
+if (seg-cur_entry.start_offset = offset) {
+current = seg-cur_entry;
+} else {
+for (it = seg-segment_list_entries_all; it; it = it-next) {
+if (it-start_offset = offset)
+current = it;
+else if (it-start_offset offset)
+break;
+}
+}
+
+offset -= current-start_offset;
+
+if (current != seg-segment_list_entry_writing) {
+int is_seekback = (current != seg-cur_entry)
seg-segment_list_entries;
+char *new_filename;
+AVIOContext *new_ctx = NULL;
+AVDictionary *options = NULL;
+
+if (!seg-seekback is_seekback)
+return AVERROR(EINVAL);
+
+new_filename = current-full_filename;
+
+if (new_filename) {
+if (is_seekback)
+av_dict_set_int(options, truncate, 0, 0);
+if ((ret = avio_open2(new_ctx, new_filename, AVIO_FLAG_WRITE,
+ s-interrupt_callback, options)) 0) {
+av_log(s, AV_LOG_ERROR, Failed to seek into segment '%s'\n,
new_filename);
+return ret;
+}
+}
+
+avio_close(seg-cur_pb);
+seg-cur_pb = new_ctx;
+seg-segment_list_entry_writing = current;
+}
+
+if (seg-cur_pb)
+if ((ret = avio_seek(seg-cur_pb, offset, SEEK_SET)) 0)
+return ret;
+
+seg-write_offset = offset;
+
+return target;
+}
+
+static int virtual_write(void *priv, uint8_t *buf, int buf_size)
+{
+AVFormatContext *s = priv;
+SegmentContext *seg = s-priv_data;
+int ret = 0;
+int written = 0;
+
+while (written buf_size) {
+SegmentListEntry *cur = seg-segment_list_entry_writing;
+size_t start = cur-start_offset + seg-write_offset;
+SegmentListEntry *next = cur-next ? cur-next : (cur ==
seg-cur_entry ? NULL : seg-cur_entry);
+size_t end = next ? next-start_offset : SIZE_MAX;
+int to_write = FFMIN(end - start, buf_size - written);
+if (seg-cur_pb)
+avio_write(seg-cur_pb, buf, to_write);
+buf += to_write;
+written += to_write;
+seg-write_offset += to_write;
+if (written buf_size)
+if ((ret = virtual_seek(s, end, SEEK_SET)) 0)
+return ret;
+}
+
+return written;
+}
+
+static void virtual_close(SegmentContext *seg)
+{
+avio_closep(seg-cur_pb);
+av_freep(seg-avf-pb);
+}
+
+static int open_virtual_ctx(AVFormatContext *s, AVIOContext **ctx)
+{
+SegmentContext *seg = s-priv_data;
+int buf_size = 32768;
+uint8_t *buf = av_malloc(buf_size);
+if (!buf)
+return AVERROR(ENOMEM);
+*ctx = avio_alloc_context(buf, buf_size, AVIO_FLAG_WRITE, s, NULL,
+ virtual_write, virtual_seek);
+if (!*ctx) {
+av_free(buf);
+return AVERROR(ENOMEM);
+}
+(*ctx)-seekable = seg-seekback;
+return virtual_seek(s, 0, SEEK_SET);
+}
+
static int segment_mux_init(AVFormatContext *s)
{
SegmentContext *seg = s-priv_data;
@@ -196,6 +320,10 @@ static int set_segment_filename(AVFormatContext *s)
return AVERROR(EINVAL);
}
+
Re: [FFmpeg-devel] [PATCH 1/2] lavf/segment: style nits
On Mon, Mar 30, 2015 at 08:23:19PM -0600, Rodger Combs wrote: --- libavformat/segment.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
---
libavcodec/tiffenc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/tiffenc.c b/libavcodec/tiffenc.c
index 44cd956..7a872a2 100644
--- a/libavcodec/tiffenc.c
+++ b/libavcodec/tiffenc.c
@@ -164,7 +164,8 @@ static int add_entry1(TiffEncoderContext *s,
* @param dst output buffer
* @param n size of input buffer
* @param compr compression method
- * @return number of output bytes. If an output error is encountered, -1 is
returned
+ * @return number of output bytes. If an output error is encountered, a
negative
+ * value corresponding to an AVERROR error code is returned.
*/
static int encode_strip(TiffEncoderContext *s, const int8_t *src,
uint8_t *dst, int n, int compr)
@@ -177,14 +178,14 @@ static int encode_strip(TiffEncoderContext *s, const
int8_t *src,
unsigned long zlen = s-buf_size - (*s-buf - s-buf_start);
if (compress(dst, zlen, src, n) != Z_OK) {
av_log(s-avctx, AV_LOG_ERROR, Compressing failed\n);
-return -1;
+return AVERROR_EXTERNAL;
}
return zlen;
}
#endif
case TIFF_RAW:
if (check_size(s, n))
-return -1;
+return AVERROR(EINVAL);
memcpy(dst, src, n);
return n;
case TIFF_PACKBITS:
@@ -193,7 +194,7 @@ static int encode_strip(TiffEncoderContext *s, const int8_t
*src,
case TIFF_LZW:
return ff_lzw_encode(s-lzws, src, n);
default:
-return -1;
+return AVERROR(EINVAL);
}
}
@@ -304,7 +305,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
default:
av_log(s-avctx, AV_LOG_ERROR,
This colors format is not supported\n);
-return -1;
+return AVERROR(EINVAL);
}
for (i = 0; i s-bpp_tab_size; i++)
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/8] png: Don't fail when a packet is larger than INT_MAX
On Mon, 30 Mar 2015 17:47:03 +0200 Michael Niedermayer michae...@gmx.at wrote: On Mon, Mar 30, 2015 at 05:11:05PM +0200, wm4 wrote: On Mon, 30 Mar 2015 13:49:08 + Donny Yang w...@kota.moe wrote: On 30 March 2015 at 02:48, Michael Niedermayer michae...@gmx.at wrote: On Sun, Mar 29, 2015 at 11:05:41AM +, Donny Yang wrote: Signed-off-by: Donny Yang w...@kota.moe --- libavcodec/pngenc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c index 3697dbb..bd3aae5 100644 --- a/libavcodec/pngenc.c +++ b/libavcodec/pngenc.c @@ -373,8 +373,6 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, enc_row_size + 12 * (((int64_t)enc_row_size + IOBUF_SIZE - 1) / IOBUF_SIZE) // 12 * ceil(enc_row_size / IOBUF_SIZE) ); -if (max_packet_size INT_MAX) -return AVERROR(ENOMEM); the check is neccessary to prevent potential integer overflows Doesn't ffmpeg support memory allocations of greater than 4 GiB? I thought it did because the memory allocation functions either accept an int64_t or size_t... No. That is false, the maximum allocation size is set by av_max_alloc() its INT_MAX by default but can be increased. This is a library-unsafe hack that shouldn't exist. Access isn't even synchronized, terrible. The reason for it being INT_MAX by default is that it limits broken media streams from allocating insane amounts of memory and by limiting below the 32bit range it protects against integer overflows in places that use int to store a size or index There are probably a bunch of situations where broken streams can do this anyway, by e.g. creating oversized linked list or arrays of pointers to big data structures (consider an array of AVPackets), so I can't take this quite seriously. Is the dimension limit on ca. 16000x16000 images intentional too? (This actually prevents ffmpeg being used to read large images.) The codebase is so rotten, The mailing lists and IRC channels exist to foster the development and use of FFmpeg. Non-constructive or off-topic messages, along with other abuses, are not welcome. libavutil/mem.c even limits memory allocations to INT_MAX. this is misleading, it limits to a user settable variable that has a default of INT_MAX In your specific case the problem is that AVPacket.size is an int. yes and no. yes, AVPacket.size could be changed to int64_t, that would need major ABI version and soname bumps of all libs though. Its something that could be done during the next such bump. but that is missing a point, AVPackets of 4GiB are very unwieldy and would be very akward to handle in applications If we do add support for frames larger than 4gb samples, then maybe a different system than storing all of it in a single array in memory should be considered. I suggest 5 dimensional storage. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
