Re: [FFmpeg-devel] [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
Hi,
On 27/06/2016 18:31, Michael Niedermayer wrote:
On Mon, Jun 27, 2016 at 02:38:50PM +0200, Benoit Fouet wrote:
h264_ps.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
ea8cc471972e1dbaa4f4f03cd7a5fe92a3b848e9
0001-h264_ps-change-decode_scaling_matrices-so-that-it-ta.patch
From c2606da98ecd04762305734f4f45ca8eaf266459 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Mon, 27 Jun 2016 12:00:39 +0200
Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
const {s,p}ps
In order to be able to make SPS const in H264ParamSets,
modify decode_scaling_matrices so that it returns if the scaling
matrix are present in the SPS, instead of altering the input SPS
structure.
---
libavcodec/h264_ps.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
please document the return value
LGTM otherwise
See if attached patch is OK in that regard.
Thanks,
--
Ben
From 67e714cbdabcb9ed808e8b10c70bbdf670cf3c2d Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Mon, 27 Jun 2016 12:00:39 +0200
Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
const {s,p}ps
In order to be able to make SPS const in H264ParamSets,
modify decode_scaling_matrices so that it returns if the scaling
matrix are present in the SPS, instead of altering the input SPS
structure.
---
libavcodec/h264_ps.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 943d953..2f166c5 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -265,8 +265,9 @@ static void decode_scaling_list(GetBitContext *gb, uint8_t
*factors, int size,
}
}
-static void decode_scaling_matrices(GetBitContext *gb, SPS *sps,
-PPS *pps, int is_sps,
+/* returns non zero if the provided SPS scaling matrix has been filled */
+static int decode_scaling_matrices(GetBitContext *gb, const SPS *sps,
+const PPS *pps, int is_sps,
uint8_t(*scaling_matrix4)[16],
uint8_t(*scaling_matrix8)[64])
{
@@ -277,8 +278,9 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS
*sps,
fallback_sps ? sps->scaling_matrix8[0] : default_scaling8[0],
fallback_sps ? sps->scaling_matrix8[3] : default_scaling8[1]
};
+int ret = 0;
if (get_bits1(gb)) {
-sps->scaling_matrix_present |= is_sps;
+ret = is_sps;
decode_scaling_list(gb, scaling_matrix4[0], 16, default_scaling4[0],
fallback[0]);// Intra, Y
decode_scaling_list(gb, scaling_matrix4[1], 16, default_scaling4[0],
scaling_matrix4[0]); // Intra, Cr
decode_scaling_list(gb, scaling_matrix4[2], 16, default_scaling4[0],
scaling_matrix4[1]); // Intra, Cb
@@ -296,6 +298,8 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS
*sps,
}
}
}
+
+return ret;
}
void ff_h264_ps_uninit(H264ParamSets *ps)
@@ -401,7 +405,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb,
AVCodecContext *avctx,
goto fail;
}
sps->transform_bypass = get_bits1(gb);
-decode_scaling_matrices(gb, sps, NULL, 1,
+sps->scaling_matrix_present |= decode_scaling_matrices(gb, sps, NULL,
1,
sps->scaling_matrix4, sps->scaling_matrix8);
} else {
sps->chroma_format_idc = 1;
--
2.9.0.37.g6d523a3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Adding new code
Hi. A question We have developed a new kind of video file and feel that ffmpeg is a good tool to help spread usage for this format. How does the dev community feel about adding a new decoder/muxer format? -- *This email and any files transmitted with it contain information from Idomoo which may be privileged and confidential and intended solely for the use of the addressee. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is strictly prohibited; please notify us immediately by* *an **email reply and delete it from your system. Idomoo accepts no liability for any personal views or opinions expressed in this email. Email transmission cannot be guaranteed to be secure or error-free. Idomoo therefore is not liable for any errors or omissions in the contents of this message, which arise as a result of email transmission.* ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/drawutils: change to support native endian only
On Mon, Jun 27, 2016 at 6:02 PM, Michael Niedermayer wrote: > On Mon, Jun 27, 2016 at 04:46:16PM +0700, Muhammad Faiz wrote: >> previously support little endian only because of fate problem >> generally native endian code is faster >> >> require 'tests/fate-run: support both le/be formats on pixfmts' >> need someone tests it on BE machine >> >> Signed-off-by: Muhammad Faiz >> --- >> libavfilter/drawutils.c | 43 -- >> libavfilter/vf_lut.c| 81 >> + >> 2 files changed, 62 insertions(+), 62 deletions(-) > > breaks fate on big endian (mips) > > Test filter-pixfmts-pad failed. Look at > tests/data/fate/filter-pixfmts-pad.err for details. > make: *** [fate-filter-pixfmts-pad] Error 1 > make: *** Waiting for unfinished jobs > --- tests/ref/fate/filter-pixfmts-lut 2016-06-26 18:25:32.960458744 +0200 > +++ tests/data/fate/filter-pixfmts-lut 2016-06-27 12:48:19.049852682 +0200 > @@ -3,38 +3,38 @@ > bgr24 fa43e3b2abfde8d9e60e157a9acc553d > bgra4e2e689897ee7a8e42b16234597bab35 > rgb24 a356171207723a580e7d277078072005 > -rgb48le 5c7dd8575836d18c91e09f1915cf9aa9 > +rgb48be d9a7669cab9159c7f28dc92387fab304 > rgba7bc854c2698b78af3e9159a19c2d9d21 > -rgba64le3a087ecab583d1930220592731f282b4 > +rgba64be612546f91b274bcc8c314386ba410c3d > yuv410p 51b39a0e33f108e652457a26667319ea > yuv411p 9204c5af92aef4922a05f58c1f6c095e > yuv420p 7c43bb0cae8dee633375c89295598508 > -yuv420p10le 1352712dd31cce78bd5441294004cf85 > -yuv420p12le c66f82da9fda458ba3abda057c58e591 > -yuv420p14le e45cb5e2a75bf6143da0b55004767f78 > -yuv420p16le eff54782c51770edfd6b84c958ac7120 > -yuv420p9le 4a6776b3379f12ad45caee8072a13695 > +yuv420p10be 4ef2f621258d77ef242e37e39b636f7c > +yuv420p12be bfb9f581c3749fd102f5bbd2065ad67a > +yuv420p14be 999d29d713e52f61a5eea1765c57e660 > +yuv420p16be a8ff20f5a96ba42fa5968bda64e160bd > +yuv420p9be 862db8509f9cbaa7fd542851047a50fc > yuv422p 67df35da0c35e54882492b2365438254 > -yuv422p10le 0158371a800294015def7f0ef66c78ea > -yuv422p12le bc49d3863ffb89658a17bf8c4fe773b0 > -yuv422p14le b55cb791d286b0b3391fe7481785e5b3 > -yuv422p16le fc3b2ba889ffaf1633000fc774307c33 > -yuv422p9le 6e2a42ae36ed5e8b5112987639728af5 > +yuv422p10be 384f3f8757ecdcb87e0f5225f92ee244 > +yuv422p12be b6bac207d387098f22b2f3613d668d30 > +yuv422p14be 48b83f5ecc7931cbab467801934bbf87 > +yuv422p16be be0db4de9820408fd6770cdcea0535f9 > +yuv422p9be f2486947acf0e98977cbec23c79871b3 > yuv440p 5e41adcfc27be4369afd217b61b2ffe3 > -yuv440p10le 8b49714bba268fb4a79b5a84223ad17a > -yuv440p12le 15ab4f453238bd9c13b18af81e22f060 > +yuv440p10be cbcbbbdbe4a1dc041bee11b757be89d7 > +yuv440p12be 7603fda62bd9cb383e7d82af0bf5fefd > yuv444p a2b58590aef88db2c1f14a1a3a3b0359 > -yuv444p10le c076c20fc808f95b34adb88aca442f48 > -yuv444p12le af8d4dd88169d5cffc2f3fce6333a94c > -yuv444p14le 93367133e25d088d4535199ed1f1ed58 > -yuv444p16le 800940feec14365ccd9b4863e38f6991 > -yuv444p9le c120044350852c4cd16a302dd1ceda79 > +yuv444p10be a3481fe5e95190749f2ac3288ad686c3 > +yuv444p12be 118c1d1f8270cebec8554972adde05da > +yuv444p14be 6671cff7f64e9f9bc1dceb3d31a69c00 > +yuv444p16be 27effaa1096361ffb6b69d1d0e8a35d6 > +yuv444p9be dcd44e88c9424d5666ac950f4e3e19e4 > yuva420p518a380bf1af60ef2ecf4754eec088e9 > -yuva420p16le72ad4fa535b007d122666ce103ef9c8b > +yuva420p16beaaa6db0ce07716dab15782dfbad5aca9 > yuva422p7110ac2e37377b05b6fc5ad967dfabb5 > -yuva422p16lee2867210660ada5784a60b4339ac52c0 > +yuva422p16bef5c06d197a1096314553b1d89f43d96f > yuva444p642f3958f141dece9e99407945e2ef43 > -yuva444p16leab04ba8acbe38085b0df650d82065eb0 > +yuva444p16be5337a7c64bd26a675d4a2bb8881e6fcb > yuvj420p65bc7c7f06a6221155ca7f9cfca4 > yuvj422pff5baffefc8ffe4547653092fd7da200 > yuvj440pef3f27270e60ac06582e3ac7c2f3e6fa Did you apply 'tests/fate-run: support both le/be formats on pixfmts' first? Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: disable the new optimizer in Visual Studio 2015 Update 3
Visual Studio 2015 Update 3 introduced a new SSA optimizer, however it unfortunately causes miscompilations. Until it is fixed, the new optimizations are disabled and should be re-checked on subsequent compiler releases. Fixes recent FATE failure on VS2015 stations. --- configure | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure b/configure index 007c953..a1d46c3 100755 --- a/configure +++ b/configure @@ -6203,6 +6203,9 @@ __declspec($_restrict) void* foo(int); EOF fi check_func strtoll || add_cflags -Dstrtoll=_strtoi64 +# the new SSA optimzer in VS2015 U3 is still mis-optimizing some parts of the code +# this flag should be re-checked on newer compiler releases and put under a version check once its fixed +check_cflags -d2SSAOptimizer- fi for pfx in "" host_; do -- 2.7.2.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: disable the new optimizer in Visual Studio 2015 Update 3
Le primidi 11 messidor, an CCXXIV, Hendrik Leppkes a écrit : > Visual Studio 2015 Update 3 introduced a new SSA optimizer, however > it unfortunately causes miscompilations. Until it is fixed, the new > optimizations are disabled and should be re-checked on subsequent > compiler releases. > > Fixes recent FATE failure on VS2015 stations. Can you put the exact FATE failure in the commit message or the comment? This would help testing later releases? > --- > configure | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configure b/configure > index 007c953..a1d46c3 100755 > --- a/configure > +++ b/configure > @@ -6203,6 +6203,9 @@ __declspec($_restrict) void* foo(int); > EOF > fi > check_func strtoll || add_cflags -Dstrtoll=_strtoi64 > +# the new SSA optimzer in VS2015 U3 is still mis-optimizing some parts > of the code > +# this flag should be re-checked on newer compiler releases and put > under a version check once its fixed Nit: rewrap to shorter lines. > +check_cflags -d2SSAOptimizer- > fi > > for pfx in "" host_; do > -- > 2.7.2.windows.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer
Le decadi 10 messidor, an CCXXIV, Stefano Sabatini a écrit :
> +The fftextdata bytestream consists of a sequence of packets. Each
> +packet starts with a timestamps expressed in a format recognized by
> +FFmpeg (see
> +@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1)
> manual,ffmpeg-utils})
> +followed by a sequence of spaces and the base64 encoded data for the
> +packet, terminated by ";". The data representation may contain
> +interleaved space characters (a space, a tab, or a newline) which are
> +ignored.
> +
> +At the moment a single stream can be represented by an fftextdata
> +bytestream.
I like the idea very much, but I feel the format is not very sympathetic to
future extensions.
I had implemented a similar feature in the past, but I did not go to the
end. My idea was to use the default output format of ffprobe (thus,
hexadecimal rather than base64). The parser works, but I was stuck with the
problem that ffprobe outputs -show_format after -show_packets. I can post
the old patch on the list if you want.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: disable the new optimizer in Visual Studio 2015 Update 3
Visual Studio 2015 Update 3 introduced a new SSA optimizer, however it unfortunately causes miscompilations. Until it is fixed, the new optimizations are disabled and should be re-checked on subsequent compiler releases. Fixes recent FATE failure of fate-lavf-pam on VS2015. --- configure | 4 1 file changed, 4 insertions(+) diff --git a/configure b/configure index 007c953..7e8c183 100755 --- a/configure +++ b/configure @@ -6203,6 +6203,10 @@ __declspec($_restrict) void* foo(int); EOF fi check_func strtoll || add_cflags -Dstrtoll=_strtoi64 +# the new SSA optimzer in VS2015 U3 is mis-optimizing some parts of the code +# this flag should be re-checked on newer compiler releases and put under a +# version check once its fixed +check_cflags -d2SSAOptimizer- fi for pfx in "" host_; do -- 2.7.2.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: disable the new optimizer in Visual Studio 2015 Update 3
On Tue, Jun 28, 2016 at 11:48 AM, Hendrik Leppkes wrote: > Visual Studio 2015 Update 3 introduced a new SSA optimizer, however > it unfortunately causes miscompilations. Until it is fixed, the new > optimizations are disabled and should be re-checked on subsequent > compiler releases. > > Fixes recent FATE failure of fate-lavf-pam on VS2015. On that note, i'm not exactly sure which code actually miscompiles. I though its pamenc, but the generated files are identical, then I though its the crc computing code (crcenc/adler32), but those seem fine as well and would likely screw up in more then one case if they would miscompile. So that leaves pnmdec, I suppose, but I didn't make much headway to poke around in that. If anyone has any handy hints how to find the code in question that might be helpful. Maybe the code is actually not-quite-right and might enjoy some straigtening. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/13] lavf: update auto-bsf to new BSF API
L'octidi 8 messidor, an CCXXIV, Marton Balint a écrit : > I thought your primary concern was the overhead which was discussed. It was only one reason amongst several; the other reasons are pretty much the usual benefits in the discussion between designing a new API for a new feature or fitting it in an existing API: more freedom in the design means simpler code, simpler API, static type safety. > As far as I know the only thing left is the "cleanness". A totally separate > list API would involve a lot of code duplication (provide the N:M API for > lists, and provide the same fields to a BSF list which are already available > as part of a BSF context. (time_base, codec parameters) Two functions and four fields, I would say it is rather reasonable. > And we only need the list API for the configuration anyway. So what if we > destroy the list after the configuration is done, and use it as a simple BSF > afterwards? > > Is it OK if the following is implemented? > > AVBSFList *list = av_bsf_list_alloc() > > // Append as many filters as you want... > av_bsf_list_append(AVBSFList *, AVBSFContext *) > > // Destroy the list structure and return the BSF context which is the // > container list filter we discussed, and which can be used as any other // > freshly allocated BSF context > av_bsf_list_finalize(AVBSFList **list, AVBSFContext **ctx) I would say it reaps about half or three quarters of the benefits of a clean API (mostly: the type safety), at the cost of being somewhat confusing. But this is assuming it can be achieved without costly overhead (malloc()s) in the empty list case. With a completely new API, it can be achieved quite easily. With a wrapping bsf, it can certainly be achieved (it is just an API, after all), but I am not sure it can be done without reworking the internal design quite a lot. Well, looking at the code, I am thinking that the current design is flawed: the extra alloc in ff_bsf_get_packet() seems completely useless, and could be removed as is without any other change in the current code, because all current filters are 1:1, it would be different for future 1:N filters. Maybe implementing ff_bsf_peek_packet() and using it to replace ff_bsf_get_packet() in 1:1 cases would do the trick. In summary: I am ok with this version IFF it works without malloc() overhead for empty lists and is reasonably simple. 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] avfilter/drawutils: change to support native endian only
On Tue, Jun 28, 2016 at 04:07:31PM +0700, Muhammad Faiz wrote: > On Mon, Jun 27, 2016 at 6:02 PM, Michael Niedermayer > wrote: > > On Mon, Jun 27, 2016 at 04:46:16PM +0700, Muhammad Faiz wrote: > >> previously support little endian only because of fate problem > >> generally native endian code is faster > >> > >> require 'tests/fate-run: support both le/be formats on pixfmts' > >> need someone tests it on BE machine > >> > >> Signed-off-by: Muhammad Faiz > >> --- > >> libavfilter/drawutils.c | 43 -- > >> libavfilter/vf_lut.c| 81 > >> + > >> 2 files changed, 62 insertions(+), 62 deletions(-) > > > > breaks fate on big endian (mips) > > > > Test filter-pixfmts-pad failed. Look at > > tests/data/fate/filter-pixfmts-pad.err for details. > > make: *** [fate-filter-pixfmts-pad] Error 1 > > make: *** Waiting for unfinished jobs > > --- tests/ref/fate/filter-pixfmts-lut 2016-06-26 18:25:32.960458744 +0200 > > +++ tests/data/fate/filter-pixfmts-lut 2016-06-27 12:48:19.049852682 +0200 > > @@ -3,38 +3,38 @@ > > bgr24 fa43e3b2abfde8d9e60e157a9acc553d > > bgra4e2e689897ee7a8e42b16234597bab35 > > rgb24 a356171207723a580e7d277078072005 > > -rgb48le 5c7dd8575836d18c91e09f1915cf9aa9 > > +rgb48be d9a7669cab9159c7f28dc92387fab304 > > rgba7bc854c2698b78af3e9159a19c2d9d21 > > -rgba64le3a087ecab583d1930220592731f282b4 > > +rgba64be612546f91b274bcc8c314386ba410c3d > > yuv410p 51b39a0e33f108e652457a26667319ea > > yuv411p 9204c5af92aef4922a05f58c1f6c095e > > yuv420p 7c43bb0cae8dee633375c89295598508 > > -yuv420p10le 1352712dd31cce78bd5441294004cf85 > > -yuv420p12le c66f82da9fda458ba3abda057c58e591 > > -yuv420p14le e45cb5e2a75bf6143da0b55004767f78 > > -yuv420p16le eff54782c51770edfd6b84c958ac7120 > > -yuv420p9le 4a6776b3379f12ad45caee8072a13695 > > +yuv420p10be 4ef2f621258d77ef242e37e39b636f7c > > +yuv420p12be bfb9f581c3749fd102f5bbd2065ad67a > > +yuv420p14be 999d29d713e52f61a5eea1765c57e660 > > +yuv420p16be a8ff20f5a96ba42fa5968bda64e160bd > > +yuv420p9be 862db8509f9cbaa7fd542851047a50fc > > yuv422p 67df35da0c35e54882492b2365438254 > > -yuv422p10le 0158371a800294015def7f0ef66c78ea > > -yuv422p12le bc49d3863ffb89658a17bf8c4fe773b0 > > -yuv422p14le b55cb791d286b0b3391fe7481785e5b3 > > -yuv422p16le fc3b2ba889ffaf1633000fc774307c33 > > -yuv422p9le 6e2a42ae36ed5e8b5112987639728af5 > > +yuv422p10be 384f3f8757ecdcb87e0f5225f92ee244 > > +yuv422p12be b6bac207d387098f22b2f3613d668d30 > > +yuv422p14be 48b83f5ecc7931cbab467801934bbf87 > > +yuv422p16be be0db4de9820408fd6770cdcea0535f9 > > +yuv422p9be f2486947acf0e98977cbec23c79871b3 > > yuv440p 5e41adcfc27be4369afd217b61b2ffe3 > > -yuv440p10le 8b49714bba268fb4a79b5a84223ad17a > > -yuv440p12le 15ab4f453238bd9c13b18af81e22f060 > > +yuv440p10be cbcbbbdbe4a1dc041bee11b757be89d7 > > +yuv440p12be 7603fda62bd9cb383e7d82af0bf5fefd > > yuv444p a2b58590aef88db2c1f14a1a3a3b0359 > > -yuv444p10le c076c20fc808f95b34adb88aca442f48 > > -yuv444p12le af8d4dd88169d5cffc2f3fce6333a94c > > -yuv444p14le 93367133e25d088d4535199ed1f1ed58 > > -yuv444p16le 800940feec14365ccd9b4863e38f6991 > > -yuv444p9le c120044350852c4cd16a302dd1ceda79 > > +yuv444p10be a3481fe5e95190749f2ac3288ad686c3 > > +yuv444p12be 118c1d1f8270cebec8554972adde05da > > +yuv444p14be 6671cff7f64e9f9bc1dceb3d31a69c00 > > +yuv444p16be 27effaa1096361ffb6b69d1d0e8a35d6 > > +yuv444p9be dcd44e88c9424d5666ac950f4e3e19e4 > > yuva420p518a380bf1af60ef2ecf4754eec088e9 > > -yuva420p16le72ad4fa535b007d122666ce103ef9c8b > > +yuva420p16beaaa6db0ce07716dab15782dfbad5aca9 > > yuva422p7110ac2e37377b05b6fc5ad967dfabb5 > > -yuva422p16lee2867210660ada5784a60b4339ac52c0 > > +yuva422p16bef5c06d197a1096314553b1d89f43d96f > > yuva444p642f3958f141dece9e99407945e2ef43 > > -yuva444p16leab04ba8acbe38085b0df650d82065eb0 > > +yuva444p16be5337a7c64bd26a675d4a2bb8881e6fcb > > yuvj420p65bc7c7f06a6221155ca7f9cfca4 > > yuvj422pff5baffefc8ffe4547653092fd7da200 > > yuvj440pef3f27270e60ac06582e3ac7c2f3e6fa > > Did you apply 'tests/fate-run: support both le/be formats on pixfmts' first? i forgot the 2nd patch but it doesnt work with it either: --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/filter-pixfmts-pad 2016-06-28 11:55:47.679606503 +0200 +++ tests/data/fate/filter-pixfmts-pad 2016-06-28 12:11:34.867626458 +0200 @@ -7,86 +7,22 @@ bgra929aac15e848038e367c250037575f9f gbrap
[FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: add missing NAL headers to SPS/PPS buffers
From: Matthieu Bouron
Fixes regression introduced by 0cd5e281df3f69c1ed8f2a72a5bcbf9691e1b5d5.
---
libavcodec/mediacodecdec_h264.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index eb63ab5..3776b67 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -112,8 +112,25 @@ static av_cold int mediacodec_decode_init(AVCodecContext
*avctx)
}
if (pps && sps) {
-ff_AMediaFormat_setBuffer(format, "csd-0", (void*)sps->data,
sps->data_size);
-ff_AMediaFormat_setBuffer(format, "csd-1", (void*)pps->data,
pps->data_size);
+uint8_t nal_headers[] = { 0x00, 0x00, 0x00, 0x01 };
+
+uint8_t *data = NULL;
+size_t data_size = FFMAX(sps->data_size, pps->data_size) +
sizeof(nal_headers);
+
+data = av_mallocz(data_size);
+if (!data) {
+ret = AVERROR(ENOMEM);
+goto done;
+}
+
+memcpy(data, nal_headers, sizeof(nal_headers));
+memcpy(data + sizeof(nal_headers), sps->data, sps->data_size);
+ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data, sps->data_size
+ sizeof(nal_headers));
+
+memcpy(data + sizeof(nal_headers), pps->data, pps->data_size);
+ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data, pps->data_size
+ sizeof(nal_headers));
+
+av_freep(&data);
} else {
av_log(avctx, AV_LOG_ERROR, "Could not extract PPS/SPS from
extradata");
ret = AVERROR_INVALIDDATA;
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: disable the new optimizer in Visual Studio 2015 Update 3
On Tue, Jun 28, 2016 at 12:01:54PM +0200, Hendrik Leppkes wrote: > On Tue, Jun 28, 2016 at 11:48 AM, Hendrik Leppkes wrote: > > Visual Studio 2015 Update 3 introduced a new SSA optimizer, however > > it unfortunately causes miscompilations. Until it is fixed, the new > > optimizations are disabled and should be re-checked on subsequent > > compiler releases. > > > > Fixes recent FATE failure of fate-lavf-pam on VS2015. > > On that note, i'm not exactly sure which code actually miscompiles. > I though its pamenc, but the generated files are identical, then I > though its the crc computing code (crcenc/adler32), but those seem > fine as well and would likely screw up in more then one case if they > would miscompile. > > So that leaves pnmdec, I suppose, but I didn't make much headway to > poke around in that. If anyone has any handy hints how to find the > code in question that might be helpful. > Maybe the code is actually not-quite-right and might enjoy some straigtening. it could be atempted to identify or confirm the file that causes the issue by building each file with its own optimization flags and use this to "bisect" over the (likely) files [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: disable the new optimizer in Visual Studio 2015 Update 3
On Tue, Jun 28, 2016 at 12:50 PM, Michael Niedermayer wrote: > On Tue, Jun 28, 2016 at 12:01:54PM +0200, Hendrik Leppkes wrote: >> On Tue, Jun 28, 2016 at 11:48 AM, Hendrik Leppkes >> wrote: >> > Visual Studio 2015 Update 3 introduced a new SSA optimizer, however >> > it unfortunately causes miscompilations. Until it is fixed, the new >> > optimizations are disabled and should be re-checked on subsequent >> > compiler releases. >> > >> > Fixes recent FATE failure of fate-lavf-pam on VS2015. >> >> On that note, i'm not exactly sure which code actually miscompiles. >> I though its pamenc, but the generated files are identical, then I >> though its the crc computing code (crcenc/adler32), but those seem >> fine as well and would likely screw up in more then one case if they >> would miscompile. >> >> So that leaves pnmdec, I suppose, but I didn't make much headway to >> poke around in that. If anyone has any handy hints how to find the >> code in question that might be helpful. >> Maybe the code is actually not-quite-right and might enjoy some straigtening. > > it could be atempted to identify or confirm the file that causes the > issue by building each file with its own optimization flags and use > this to "bisect" over the (likely) files > I confirmed its pnmdec.c, and only in the monoblack case. For some reason its somehow related to the init_put_bits line, if i change that in any way (ie. by adding 1 to the linesize), it passes. If i have some time later, I might look at the asm. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add ppm pipe demuxer
On Thu, Jun 16, 2016 at 11:04:30AM +0200, Clément Bœsch wrote: > On Fri, Jun 10, 2016 at 04:28:55AM +0200, Michael Niedermayer wrote: > > On Thu, Jun 09, 2016 at 04:35:02PM +0200, Clément Bœsch wrote: > > > On Thu, Jun 09, 2016 at 03:59:30PM +0200, Clément Bœsch wrote: > > > > On Thu, Jun 09, 2016 at 01:35:19PM +, Carl Eugen Hoyos wrote: > > > > > Clément Bœsch pkh.me> writes: > > > > > > > > > > > +if (b[3] == '#') > > > > > > +return AVPROBE_SCORE_EXTENSION + 1; > > > > > > +if (b[3] >= '0' && b[3] <= '9') > > > > > > +return AVPROBE_SCORE_MAX - 1; > > > > > > > > > > Imo, this should be: > > > > > if (b[3] == '#' || (b[3] >= '0' && b[3] <= '9')) > > > > > return AVPROBE_SCORE_EXTENSION + 2; > > > > > or similar > > > > > > > > > > I count 37 and 34 bits which is only a little more than > > > > > the usual 32 bit for EXTENSION + 1. > > > > > > > > > > > > > Sure. Changed locally, will push soon, thanks. > > > > > > > > > > For some reasons it makes seeking with pgm somehow working. The reference > > > test doesn't look that great IIUC, but seeking in these file with ffplay > > > is fine AFAICT. > > > > it seems it messes with pgmyuv detection (which i think was filename > > extension based) > > > > example: > > ./ffmpeg -i matrixbench_mpeg2.mpg -pix_fmt yuv420p16be -vframes 1 > > test.pgmyuv > > > ./ffplay-ref test.pgmyuv > > Input #0, image2, from 'test.pgmyuv':B vq=0KB sq=0B f=0/0 > > Duration: 00:00:00.04, start: 0.00, bitrate: 248835 kb/s > > Stream #0:0: Video: pgmyuv, yuv420p16le, 720x576, 25 tbr, 25 tbn > > > > This currently crashes for me with git/master: > > pnm_decode_frame (avctx=, data=0x7fffe8012f40, > got_frame=0x7fffecbe89cc, avpkt=) at > src/libavcodec/pnmdec.c:225 > 225 v = av_be2ne16(((uint16_t *)s->bytestream)[j]); > (gdb) bt disassembly and register values could be interresting [...] -- 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
[FFmpeg-devel] how to use two rtmp plugins in ffmpeg
Hi, ffmpeg has its own built-in rtmp plugin, and also support to use rtmpdump as another rtmp plugin. How to use specified rtmp plugin, i.e. build-in rtmp plugin or rtmpdump plugin, if rtmpdump is enabled and built within ffmpeg? Thanks! Regards Andrew ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/13] lavf: update auto-bsf to new BSF API
Le primidi 11 messidor, an CCXXIV, Nicolas George a écrit : > Well, looking at the code, I am thinking that the current design is flawed: > the extra alloc in ff_bsf_get_packet() seems completely useless, and could > be removed as is without any other change in the current code, because all > current filters are 1:1, it would be different for future 1:N filters. Maybe > implementing ff_bsf_peek_packet() and using it to replace > ff_bsf_get_packet() in 1:1 cases would do the trick. I have checked that the following quick-and-dirty changes pass FATE. Making it in shape (testing filters not covered by FATE, making future-proof) would take time that I would like to spend on lavfi right now. But it proves the overhead can be reduced easily. Regards, -- Nicolas George diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c index 88b7f29..05fa1e3 100644 --- a/libavcodec/bsf.c +++ b/libavcodec/bsf.c @@ -208,12 +208,7 @@ int ff_bsf_get_packet(AVBSFContext *ctx, AVPacket **pkt) !ctx->internal->buffer_pkt->side_data_elems) return AVERROR(EAGAIN); -tmp_pkt = av_packet_alloc(); -if (!tmp_pkt) -return AVERROR(ENOMEM); - *pkt = ctx->internal->buffer_pkt; -ctx->internal->buffer_pkt = tmp_pkt; return 0; } diff --git a/libavcodec/h264_mp4toannexb_bsf.c b/libavcodec/h264_mp4toannexb_bsf.c index 163d0f5..26e26c0 100644 --- a/libavcodec/h264_mp4toannexb_bsf.c +++ b/libavcodec/h264_mp4toannexb_bsf.c @@ -274,7 +274,7 @@ next_nal: fail: if (ret < 0) av_packet_unref(out); -av_packet_free(&in); +av_packet_unref(in); return ret; } diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c b/libavcodec/mpeg4_unpack_bframes_bsf.c index 0615621..257efaf 100644 --- a/libavcodec/mpeg4_unpack_bframes_bsf.c +++ b/libavcodec/mpeg4_unpack_bframes_bsf.c @@ -151,7 +151,7 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, AVPacket *out) av_packet_move_ref(out, in); } -av_packet_free(&in); +av_packet_unref(in); return 0; } diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c index b686adb..9391fcb 100644 --- a/libavcodec/vp9_superframe_bsf.c +++ b/libavcodec/vp9_superframe_bsf.c @@ -178,7 +178,7 @@ static int vp9_superframe_filter(AVBSFContext *ctx, AVPacket *out) done: if (res < 0) av_packet_unref(out); -av_packet_free(&in); +av_packet_unref(in); return res; } signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] libavcodec/exr : fix decoding float piz file
Hello,
in attach patch to fix piz float file (ticket 5674)
the size of a channel is now calculate using the pixel type.
Comments welcome
Martin
Jokyo Images
From b3edf5888e75110b0b2bf4af3f95a6fb50f8e82a Mon Sep 17 00:00:00 2001
From: Martin Vignali
Date: Tue, 28 Jun 2016 13:23:43 +0200
Subject: [PATCH] libavcodec/exr : fix decoding piz float file.
fix ticket #5674
the size of data to process in piz_uncompress, is now calc
using the pixel type of each channel.
the data reorganization, alos take care about the size of
each channel
---
libavcodec/exr.c | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index c87187c..528ae90 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -749,6 +749,9 @@ static int piz_uncompress(EXRContext *s, const uint8_t *src, int ssize,
uint16_t *tmp = (uint16_t *)td->tmp;
uint8_t *out;
int ret, i, j;
+int pixel_half_size;/* 1 for half, 2 for float and uint32 */
+EXRChannel *channel;
+int tmp_offset;
if (!td->bitmap)
td->bitmap = av_malloc(BITMAP_SIZE);
@@ -781,24 +784,37 @@ static int piz_uncompress(EXRContext *s, const uint8_t *src, int ssize,
ptr = tmp;
for (i = 0; i < s->nb_channels; i++) {
-EXRChannel *channel = &s->channels[i];
-int size = channel->pixel_type;
+channel = &s->channels[i];
-for (j = 0; j < size; j++)
-wav_decode(ptr + j, td->xsize, size, td->ysize,
- td->xsize * size, maxval);
-ptr += td->xsize * td->ysize * size;
+if (channel->pixel_type == EXR_HALF)
+pixel_half_size = 1;
+else
+pixel_half_size = 2;
+
+for (j = 0; j < pixel_half_size; j++)
+wav_decode(ptr + j, td->xsize, pixel_half_size, td->ysize,
+ td->xsize * pixel_half_size, maxval);
+ptr += td->xsize * td->ysize * pixel_half_size;
}
apply_lut(td->lut, tmp, dsize / sizeof(uint16_t));
out = td->uncompressed_data;
-for (i = 0; i < td->ysize; i++)
+for (i = 0; i < td->ysize; i++) {
+tmp_offset = 0;
for (j = 0; j < s->nb_channels; j++) {
-uint16_t *in = tmp + j * td->xsize * td->ysize + i * td->xsize;
-memcpy(out, in, td->xsize * 2);
-out += td->xsize * 2;
+EXRChannel *channel = &s->channels[j];
+if (channel->pixel_type == EXR_HALF)
+pixel_half_size = 1;
+else
+pixel_half_size = 2;
+
+uint16_t *in = tmp + tmp_offset * td->xsize * td->ysize + i * td->xsize * pixel_half_size;
+tmp_offset += pixel_half_size;
+memcpy(out, in, td->xsize * 2 * pixel_half_size);
+out += td->xsize * 2 * pixel_half_size;
}
+}
return 0;
}
--
1.9.3 (Apple Git-50)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [GSoC][PATCH] Add FIFO muxer
From: Jan Sebechlebsky Hello, I'm sending the patch with implementation of discussed FIFO pseudo-muxer which is part of my GSoC project. The muxer allows to separate decoder from the actual muxer (or several muxers when combined with tee). Trasparent recovery from failure is also implemented. I'll appreciate feedback Best regards, Jan Jan Sebechlebsky (1): libavformat: Add FIFO pseudo-muxer configure| 1 + doc/muxers.texi | 77 ++ libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/fifo.c | 657 +++ 5 files changed, 737 insertions(+) create mode 100644 libavformat/fifo.c -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/13] lavf: update auto-bsf to new BSF API
On 06/28/2016 12:10 PM, Nicolas George wrote: In summary: I am ok with this version IFF it works without malloc() overhead for empty lists and is reasonably simple. I think I can start to work on this. I think it can be done without dynamic allocation. Apart from that - do you think it would be worth a try to implement memory pool for AVPacket allocation ? Regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer
From: Jan Sebechlebsky
FIFO pseudo-muxer allows to separate decoder from the
actual output by using first-in-first-out queue and
running actual muxer asynchronously in separate thread.
It can be configured to attempt transparent recovery
of output on failure.
Signed-off-by: Jan Sebechlebsky
---
configure| 1 +
doc/muxers.texi | 77 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/fifo.c | 657 +++
5 files changed, 737 insertions(+)
create mode 100644 libavformat/fifo.c
diff --git a/configure b/configure
index 007c953..eacda09 100755
--- a/configure
+++ b/configure
@@ -2826,6 +2826,7 @@ dv_muxer_select="dvprofile"
dxa_demuxer_select="riffdec"
eac3_demuxer_select="ac3_parser"
f4v_muxer_select="mov_muxer"
+fifo_muxer_deps="pthreads"
flac_demuxer_select="flac_parser"
hds_muxer_select="flv_muxer"
hls_muxer_select="mpegts_muxer"
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2ca0ba..e545bc7 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1408,6 +1408,83 @@ Specify whether to remove all fragments when finished.
Default 0 (do not remove)
@end table
+@section fifo
+
+The fifo pseudo-muxer allows to separate encoding from any other muxer
+by using first-in-first-out queue and running the actual muxer in separate
+thread. This is especially useful in combination with tee muxer
+and output to several destinations with different reliability/writing
speed/latency.
+
+The fifo muxer can operate in regular or fully non-blocking mode. This
determines
+the behaviour in case the queue fills up. In regular mode the encoding is
blocked
+until muxer processes some of the packets from queue, in non-blocking mode the
packets
+are thrown away rather than blocking the encoder (this might be useful in
real-time
+streaming scenario).
+
+@table @option
+
+@item fifo_format
+Specify the format name. Useful if it cannot be guessed from the
+output name suffix.
+
+@item queue_size
+Specify size of the queue (number of packets)
+
+@item format_opts
+Specify format options for the underlying muxer. Muxer options can be specified
+as a list of @var{key}=@var{value} pairs separated by ':'.
+
+@item block_on_overflow 0|1
+If set to 0, fully non-blocking mode will be used and in case the queue
+fills up, packets will be dropped. By default this option is set to 1,
+so in case of queue overflow the encoder will be block until muxer
+processes some of the packets.
+
+@item attempt_recovery 0|1
+If failure happens, attempt to recover the output. This is especially useful
+when used with network output, allows to restart streaming transparently.
+By default this option is turned off.
+
+@item max_recovery_attempts
+Sets maximal number of successive unsucessfull recovery attempts after which
+the output fails permanently. Unlimited if set to zero.
+
+@item recovery_wait_time
+Waiting time before the next recovery attempt after previous unsuccessfull
+recovery attempt.
+
+@item recovery_wait_streamtime 0|1
+If set to 0 (default), the real time is used when waiting for the recovery
attempt
+(i.e. the recovery will be attempted after at least recovery_wait_time
seconds).
+If set to 1, the time of the processed stream is taken into account instead
+(i.e. the recovery will be attempted after at least recovery_wait_time seconds
+of the stream is ommited).
+
+@item recover_any_error 0|1
+If set to 1, recovery will be attempted regardless of type of the error causing
+the failure (by default, in case of certain errors the recovery is not
attempted
+even when attempt_recovery is on).
+
+@item restart_with_keyframe 0|1
+Specify whether to wait for the keyframe after recovering from
+queue overflow or failure.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+Stream something to rtmp server using non-blocking mode and recover
automatically
+in case failure happens (for example the network becomes unavailable for a
moment).
+@example
+ffmpeg -re -i ... -c:v libx264 -c:a mp2 -f fifo -fifo_format flv -map 0:v -map
0:a
+ -block_on_overflow 0 -attempt_recovery 1 rtmp://example.com/live/stream_name
+@end example
+
+@end itemize
+
@section tee
The tee muxer can be used to write the same data to several files or any
diff --git a/libavformat/Makefile b/libavformat/Makefile
index c49f9de..42fb9be 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -162,6 +162,7 @@ OBJS-$(CONFIG_FFM_DEMUXER) += ffmdec.o
OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
OBJS-$(CONFIG_FFMETADATA_MUXER) += ffmetaenc.o
+OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
OBJS-$(CONFIG_FILMSTRIP_MUXER) += filmstripenc.o
OBJS-$(CONFIG_FLAC_DEMUXER) += flacdec.o rawdec.o \
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index
Re: [FFmpeg-devel] how to use two rtmp plugins in ffmpeg
If librtmp is enabled FFmpeg will only use it. You can't select one or the other on runtime. On 28 June 2016 at 12:14, qw wrote: > Hi, > > ffmpeg has its own built-in rtmp plugin, and also support to use rtmpdump as > another rtmp plugin. > > How to use specified rtmp plugin, i.e. build-in rtmp plugin or rtmpdump > plugin, if rtmpdump is enabled and built within ffmpeg? > > Thanks! > > Regards > > Andrew > ___ > 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] libavformat: Add FIFO pseudo-muxer
Le primidi 11 messidor, an CCXXIV, sebechlebsky...@gmail.com a écrit :
> From: Jan Sebechlebsky
>
> FIFO pseudo-muxer allows to separate decoder from the
> actual output by using first-in-first-out queue and
> running actual muxer asynchronously in separate thread.
>
> It can be configured to attempt transparent recovery
> of output on failure.
>
> Signed-off-by: Jan Sebechlebsky
> ---
> configure| 1 +
> doc/muxers.texi | 77 ++
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/fifo.c | 657
> +++
> 5 files changed, 737 insertions(+)
> create mode 100644 libavformat/fifo.c
>
> diff --git a/configure b/configure
> index 007c953..eacda09 100755
> --- a/configure
> +++ b/configure
> @@ -2826,6 +2826,7 @@ dv_muxer_select="dvprofile"
> dxa_demuxer_select="riffdec"
> eac3_demuxer_select="ac3_parser"
> f4v_muxer_select="mov_muxer"
> +fifo_muxer_deps="pthreads"
> flac_demuxer_select="flac_parser"
> hds_muxer_select="flv_muxer"
> hls_muxer_select="mpegts_muxer"
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index c2ca0ba..e545bc7 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1408,6 +1408,83 @@ Specify whether to remove all fragments when finished.
> Default 0 (do not remove)
>
> @end table
>
> +@section fifo
> +
> +The fifo pseudo-muxer allows to separate encoding from any other muxer
> +by using first-in-first-out queue and running the actual muxer in separate
> +thread. This is especially useful in combination with tee muxer
> +and output to several destinations with different reliability/writing
> speed/latency.
> +
> +The fifo muxer can operate in regular or fully non-blocking mode. This
> determines
Not true: the current code is non-blocking for packets, but not for the
trailer. It can not be really non-blocking but as is it can block
indefinitely.
> +the behaviour in case the queue fills up. In regular mode the encoding is
> blocked
> +until muxer processes some of the packets from queue, in non-blocking mode
> the packets
> +are thrown away rather than blocking the encoder (this might be useful in
> real-time
> +streaming scenario).
Nit: lines <80 chars.
> +
> +@table @option
> +
> +@item fifo_format
> +Specify the format name. Useful if it cannot be guessed from the
> +output name suffix.
This option is defined but never used.
> +
> +@item queue_size
> +Specify size of the queue (number of packets)
> +
> +@item format_opts
> +Specify format options for the underlying muxer. Muxer options can be
> specified
> +as a list of @var{key}=@var{value} pairs separated by ':'.
Yay, another trip to escaping hell!
> +
> +@item block_on_overflow 0|1
Nit: "0|1" is unusual.
> +If set to 0, fully non-blocking mode will be used and in case the queue
> +fills up, packets will be dropped. By default this option is set to 1,
> +so in case of queue overflow the encoder will be block until muxer
> +processes some of the packets.
IMHO, this should use AVFMT_FLAG_NONBLOCK.
> +
> +@item attempt_recovery 0|1
> +If failure happens, attempt to recover the output. This is especially useful
> +when used with network output, allows to restart streaming transparently.
> +By default this option is turned off.
> +
> +@item max_recovery_attempts
> +Sets maximal number of successive unsucessfull recovery attempts after which
> +the output fails permanently. Unlimited if set to zero.
> +
> +@item recovery_wait_time
> +Waiting time before the next recovery attempt after previous unsuccessfull
> +recovery attempt.
> +
> +@item recovery_wait_streamtime 0|1
> +If set to 0 (default), the real time is used when waiting for the recovery
> attempt
> +(i.e. the recovery will be attempted after at least recovery_wait_time
> seconds).
> +If set to 1, the time of the processed stream is taken into account instead
> +(i.e. the recovery will be attempted after at least recovery_wait_time
> seconds
> +of the stream is ommited).
> +
> +@item recover_any_error 0|1
> +If set to 1, recovery will be attempted regardless of type of the error
> causing
> +the failure (by default, in case of certain errors the recovery is not
> attempted
> +even when attempt_recovery is on).
> +
> +@item restart_with_keyframe 0|1
> +Specify whether to wait for the keyframe after recovering from
> +queue overflow or failure.
> +
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +
> +@item
> +Stream something to rtmp server using non-blocking mode and recover
> automatically
> +in case failure happens (for example the network becomes unavailable for a
> moment).
> +@example
> +ffmpeg -re -i ... -c:v libx264 -c:a mp2 -f fifo -fifo_format flv -map 0:v
> -map 0:a
> + -block_on_overflow 0 -attempt_recovery 1
> rtmp://example.com/live/stream_name
> +@end example
> +
> +@end itemize
> +
> @section tee
>
> The tee muxer can be used to write the same data to several files or any
> diff --git
[FFmpeg-devel] [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
before patched:
[root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c copy -f
hls -v verbose -y .m3u8
ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg
developers
built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-17)
configuration: --prefix=/usr/ --libdir=/usr/lib64 --enable-libx264
--enable-libfaac --enable-gpl --enable-nonfree
libavutil 55. 27.100 / 55. 27.100
libavcodec 57. 48.101 / 57. 48.101
libavformat57. 40.101 / 57. 40.101
libavdevice57. 0.102 / 57. 0.102
libavfilter 6. 46.102 / 6. 46.102
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc54. 0.100 / 54. 0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/root/facebook.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf57.34.103
Duration: 00:45:45.64, start: 0.00, bitrate: 1530 kb/s
Stream #0:0(und): Video: h264 (High), 1 reference frame (avc1 /
0x31637661), yuv420p, 720x528 [SAR 1:1 DAR 15:11], 1141 kb/s, 25 fps, 25
tbr, 16k tbn, 50 tbc (default)
Metadata:
handler_name: VideoHandler
Stream #0:1(und): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side),
fltp, 384 kb/s (default)
Metadata:
handler_name: SoundHandler
Side data:
audio service type: main
[hls @ 0x2e49540] Using AVStream.codec to pass codec parameters to muxers
is deprecated, use AVStream.codecpar instead.
Last message repeated 1 times
[mpegts @ 0x2e457a0] muxrate VBR, pcr every 5 pkts, sdt every 2147483647,
pat/pmt every 2147483647 pkts
Output #0, hls, to '.m3u8':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf57.40.101
Stream #0:0(und): Video: h264, 1 reference frame (avc1 / 0x31637661),
yuv420p, 720x528 (0x0) [SAR 1:1 DAR 15:11], q=2-31, 1141 kb/s, 25 fps, 25
tbr, 90k tbn, 50 tbc (default)
Metadata:
handler_name: VideoHandler
Stream #0:1(und): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side),
384 kb/s (default)
Metadata:
handler_name: SoundHandler
Side data:
audio service type: main
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[mpegts @ 0x2e457a0] H.264 bitstream malformed, no startcode found, use the
video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v
h264_mp4toannexb' option with ffmpeg)
av_interleaved_write_frame(): Invalid data found when processing input
No more output streams to write to, finishing.
[mpegts @ 0x2e457a0] H.264 bitstream malformed, no startcode found, use the
video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v
h264_mp4toannexb' option with ffmpeg)
[hls @ 0x2e49540] EXT-X-MEDIA-SEQUENCE:0
Error writing trailer of .m3u8: Invalid data found when processing
inputframe=3 fps=0.0 q=-1.0 Lsize=N/A time=00:00:00.03 bitrate=N/A
speed=1.42x
video:18kB audio:2kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
Input file #0 (/root/facebook.mp4):
Input stream #0:0 (video): 3 packets read (18793 bytes);
Input stream #0:1 (audio): 1 packets read (1536 bytes);
Total: 4 packets (20329 bytes) demuxed
Output file #0 (.m3u8):
Output stream #0:0 (video): 3 packets muxed (18793 bytes);
Output stream #0:1 (audio): 1 packets muxed (1536 bytes);
Total: 4 packets (20329 bytes) muxed
Conversion failed!
after patched:
[root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c copy -f
hls -v verbose -y .m3u8
ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg
developers
built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-17)
configuration: --prefix=/usr/ --libdir=/usr/lib64 --enable-libx264
--enable-libfaac --enable-gpl --enable-nonfree
libavutil 55. 27.100 / 55. 27.100
libavcodec 57. 48.101 / 57. 48.101
libavformat57. 40.101 / 57. 40.101
libavdevice57. 0.102 / 57. 0.102
libavfilter 6. 46.102 / 6. 46.102
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc54. 0.100 / 54. 0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/root/facebook.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf57.34.103
Duration: 00:45:45.64, start: 0.00, bitrate: 1530 kb/s
Stream #0:0(und): Video: h264 (High), 1 reference frame (avc1 /
0x31637661), yuv420p, 720x528 [SAR 1:1 DAR 15:11], 1141 kb/s, 25 fps, 25
tbr, 16k tbn, 50 tbc (default)
Metadata:
handler_name: VideoHandler
Stream #0:1(und): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side),
fltp, 384 kb/s (default)
Metadata:
handler_name: SoundHandler
Side data:
audio service type: main
[hls @ 0x3dfa540] Using AVStream.codec to pass codec parameters to muxers
is deprecated, use AVStream.codecpar instead.
Re: [FFmpeg-devel] how to download specific track data of a m3u8 content?
2016-06-28 14:26 GMT+08:00 aihua zhao : > Hi Experts: > > I use ffmpeg to parse/demux media content, and created a player basing on > it. > > here is a m3u8 content: > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8 > < > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200 > > > there are three video track in it. > > I found all video/audio tracks are downloaded during playback, and I can > switch different track on the fly. > however, it consumes much bandwidth since all tracks are downloaded. > > even when I append bandwidth to the url; still the same result: > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200 > > Is there any way to download the specified track only to save bandwidth? > > thanks > Hi Aihua Zhao, If you haven't read the m3u8 file and parse the playlist, and read the sub m3u8 playlist, how do you get the info of the mpegts? So it's must readahead the list and list all of the track for choose. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer
Hello Nicolas,
On 06/28/2016 03:42 PM, Nicolas George wrote:
+The fifo pseudo-muxer allows to separate encoding from any other muxer
+by using first-in-first-out queue and running the actual muxer in separate
+thread. This is especially useful in combination with tee muxer
+and output to several destinations with different reliability/writing
speed/latency.
+
+The fifo muxer can operate in regular or fully non-blocking mode. This
determines
Not true: the current code is non-blocking for packets, but not for the
trailer. It can not be really non-blocking but as is it can block
indefinitely.
+the behaviour in case the queue fills up. In regular mode the encoding is
blocked
+until muxer processes some of the packets from queue, in non-blocking mode the
packets
+are thrown away rather than blocking the encoder (this might be useful in
real-time
+streaming scenario).
Would it be ok to call it "asynchronous"?
+@item fifo_format
+Specify the format name. Useful if it cannot be guessed from the
+output name suffix.
This option is defined but never used.
I don't understand this note - the fifo_format option is used (and seems
to work)?
+
+@item queue_size
+Specify size of the queue (number of packets)
+
+@item format_opts
+Specify format options for the underlying muxer. Muxer options can be specified
+as a list of @var{key}=@var{value} pairs separated by ':'.
Yay, another trip to escaping hell!
Unfortunately :( Do you think cmd muxer initialization could be easily
modified in a way that muxer would also get access to option dictionary?
+if (!(avf2->oformat->flags & AVFMT_NOFILE)) {
+ret = avf2->io_open(avf2, &avf2->pb, avf->filename, AVIO_FLAG_WRITE,
&format_options);
+if (ret < 0) {
+av_log(avf, AV_LOG_ERROR, "Error opening %s: %s\n",
+ avf->filename, av_err2str(ret));
+goto end;
+}
+}
Why do we not have a utility function for that?
I'll create ff_format_io_open and, this can be refactored in other
muxer, too.
+s_idx = pkt->stream_index;
+src_tb = avf->streams[s_idx]->time_base;
+dst_tb = avf2->streams[s_idx]->time_base;
+
+pkt->pts = av_rescale_q(pkt->pts, src_tb, dst_tb);
+pkt->dts = av_rescale_q(pkt->dts, src_tb, dst_tb);
+pkt->duration = av_rescale_q(pkt->duration, src_tb, dst_tb);
This looks suspicious.
For starters, it does not handle the NOPTS value, but that is an easy fix.
More worryingly, it looks that the application does not see the time base
selected by the real muxer. It could be a problem.
I'll change it to handle NOPTS (the same should be done for tee muxer,
so I'll patch that too). Can you specify what could be the problem when
the application does not see the time base of real muxer? If it was
really neccessary, I can make write_header call before actually
executing the thread (so only write_packet calls would be non-blocking)
and copy the selected timebase, however, I prefer write_header to be
executed in consumer thread. Also, this situation is impossible to
handle in tee muxer, since every slave muxer can select different time base.
+/* Check and solve overflow */
+pthread_mutex_lock(&fifo->overflow_flag_lock);
+if (fifo->overflow_flag) {
+av_thread_message_flush(queue);
+if (fifo->restart_with_keyframe)
+fifo->drop_until_keyframe = 1;
+fifo->overflow_flag = 0;
+just_flushed = 1;
+}
+pthread_mutex_unlock(&fifo->overflow_flag_lock);
I think the communication logic here needs an extensive comment here.
And I am a bit worried about the extra lock: mixing several communication
mechanisms between threads is a recipe for headache.
I'll add the comment. I've tried to do this without the extra lock at
first by setting error to the thread message queue and adding
threadmessage queue flag which allows the error to be returned
immediately, but I think using this single extra lock is really cleaner
solution, I would prefer that.
+avf2->io_close = avf->io_close;
+avf2->io_open = avf->io_open;
This could be dangerous too, I am not sure these functions are guaranteed to
be thread-safe. It needs at least documentation.
I'll try to check existing functions for dangerous operations - I guess
we could add a note to documentation saying that the io_{open,close}
should be thread-safe.
+st2->r_frame_rate= st->r_frame_rate;
+st2->time_base = st->time_base;
+st2->start_time = st->start_time;
+st2->duration= st->duration;
+st2->nb_frames = st->nb_frames;
+st2->disposition = st->disposition;
+st2->sample_aspect_ratio = st->sample_aspect_ratio;
+st2->avg_frame_rate = st->avg_frame_rate;
Why do we not have an utility function for that (bis)?
I've actually created the function av_stream_encode_params_copy:
https://github.com/jsebechlebs
Re: [FFmpeg-devel] [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu wrote: > before patched: > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c copy -f > hls -v verbose -y .m3u8 > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg > developers The way I see it, the auto bsf from the mpegts muxer should already cover this without changes? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] ogg audio muxing bug and patch
Attached patch fixes an int<-->uint bug affecting muxing of ogg audio. This line is the problem: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/oggparsevorbis.c#L476 You can see in: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/oggdec.h#L68 that `os->pduration` is an `unsigned int`, but over at https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/oggparsevorbis.c#L409 the `duration` local is just an `int`... So when `duration` is negative, it's getting converted to a large positive 32-bit unsigned int. ab pduration.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/exr : fix decoding float piz file
On 6/28/16, Martin Vignali wrote: > Hello, > > in attach patch to fix piz float file (ticket 5674) > > the size of a channel is now calculate using the pixel type. > > Comments welcome > > Martin > Jokyo Images > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation
On Wed, 2016-06-22 at 20:33 -0300, James Almer wrote:
> On 6/22/2016 8:15 PM, Dan Parrot wrote:
> > On Thu, 2016-06-23 at 01:03 +0200, Michael Niedermayer wrote:
> >> On Tue, Jun 21, 2016 at 12:04:42AM -0500, Dan Parrot wrote:
> >>> On Tue, 2016-06-21 at 02:22 +0200, Michael Niedermayer wrote:
> On Mon, Jun 20, 2016 at 06:38:18PM -0500, Dan Parrot wrote:
> > On Tue, 2016-06-21 at 01:06 +0200, Michael Niedermayer wrote:
> >> On Mon, Jun 20, 2016 at 05:55:47PM -0500, Dan Parrot wrote:
> >>> On Tue, 2016-06-21 at 00:45 +0200, Michael Niedermayer wrote:
> On Sun, Jun 19, 2016 at 09:57:42PM +, Dan Parrot wrote:
> > First commit addressing Trac ticket #5570. Functions defined in
> > libswscale/input.c
> > have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
> > ---
> > libswscale/ppc/Makefile |1 +
> > libswscale/ppc/input_vsx.c| 1070
> > +
> > libswscale/swscale.c |3 +
> > libswscale/swscale_internal.h |1 +
> > 4 files changed, 1075 insertions(+)
> > create mode 100644 libswscale/ppc/input_vsx.c
> >
> > diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
> > index d1b596e..2482893 100644
> > --- a/libswscale/ppc/Makefile
> > +++ b/libswscale/ppc/Makefile
> > @@ -1,3 +1,4 @@
> > OBJS += ppc/swscale_altivec.o
> > \
> > +ppc/input_vsx.o
> > \
> > ppc/yuv2rgb_altivec.o
> > \
> > ppc/yuv2yuv_altivec.o
> > \
> > diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
> > new file mode 100644
> > index 000..adb0e38
> > --- /dev/null
> > +++ b/libswscale/ppc/input_vsx.c
> > @@ -0,0 +1,1070 @@
> > +/*
> > + * Copyright (C) 2016 Dan Parrot
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later
> > version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "libavutil/avutil.h"
> > +#include "libavutil/bswap.h"
> > +#include "libavutil/cpu.h"
> > +#include "libavutil/intreadwrite.h"
> > +#include "libavutil/mathematics.h"
> > +#include "libavutil/pixdesc.h"
> > +#include "libavutil/avassert.h"
> > +#include "config.h"
> > +#include "libswscale/rgb2rgb.h"
> > +#include "libswscale/swscale.h"
> > +#include "libswscale/swscale_internal.h"
> > +
> > +#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) :
> > AV_RL16(pos))
> > +
> > +#define r ((origin == AV_PIX_FMT_BGR48BE || origin ==
> > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin ==
> > AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
> > +#define b ((origin == AV_PIX_FMT_BGR48BE || origin ==
> > AV_PIX_FMT_BGR48LE || origin == AV_PIX_FMT_BGRA64BE || origin ==
> > AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
> > +
> > +#if HAVE_VSX
> > +
> > +// This is a SIMD version for IBM POWER8 of function
> > rgb64ToY_c_template
> > +// in file libswscale/input.c
> > +static av_always_inline void
> > +rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int
> > width,
> > +enum AVPixelFormat origin, int32_t
> > *rgb2yuv)
> > +{
> > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by =
> > rgb2yuv[BY_IDX];
> > +int i, j;
> > +int num_vec, frag;
> > +
> > +num_vec = width / 8;
> > +frag=
Re: [FFmpeg-devel] fate/webp : add test for lossy files
2016-06-26 20:41 GMT+02:00 Michael Niedermayer : > On Sun, Jun 26, 2016 at 12:52:00PM +0200, Martin Vignali wrote: > > Hello, > > > > in attach a patch to add test for lossy decoding of webp. > > > > Compare with dwebp tool, the result of ffmpeg in yuv is exactly the same > > than the official decoder. > > > > (trouble report in my previous email, concern rgb/rgba output (because > the > > filtering yuv420 -> yuv444 of libwebp is not implemented). > > > > > Samples can be found here : https://we.tl/QKy6uyDJpx > > > > and need to be put in ./fate-suite/webp/ > > uploaded > thx > > ping for the patch. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/webp : add test for lossy files
On 6/28/2016 5:43 PM, Martin Vignali wrote: > 2016-06-26 20:41 GMT+02:00 Michael Niedermayer : > >> On Sun, Jun 26, 2016 at 12:52:00PM +0200, Martin Vignali wrote: >>> Hello, >>> >>> in attach a patch to add test for lossy decoding of webp. >>> >>> Compare with dwebp tool, the result of ffmpeg in yuv is exactly the same >>> than the official decoder. >>> >>> (trouble report in my previous email, concern rgb/rgba output (because >> the >>> filtering yuv420 -> yuv444 of libwebp is not implemented). >>> >> >>> Samples can be found here : https://we.tl/QKy6uyDJpx >>> >>> and need to be put in ./fate-suite/webp/ >> >> uploaded >> thx >> >> ping for the patch. > > Martin Applied, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
2016-06-29 0:16 GMT+08:00 Hendrik Leppkes :
> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu
> wrote:
> > before patched:
> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c copy -f
> > hls -v verbose -y .m3u8
> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg
> > developers
>
>
> The way I see it, the auto bsf from the mpegts muxer should already
> cover this without changes?
>
add the hls_check_bitstream into hls format and call the hls->avf to call
the mpegtsenc's check_bitstream,
don't do this operation, it won't call the mpegtsenc's check_bitstream,
look at the message bellow:
ffmpeg version N-80694-g074fdf4 Copyright (c) 2000-2016 the FFmpeg
developers
built with Apple LLVM version 7.3.0 (clang-703.0.31)
configuration: --enable-libass --enable-opengl --enable-libx264
--enable-libmp3lame --enable-gpl --enable-libfaac --enable-nonfree
--prefix=/usr/local --enable-libopencv --enable-libtesseract
libavutil 55. 26.100 / 55. 26.100
libavcodec 57. 47.100 / 57. 47.100
libavformat57. 40.101 / 57. 40.101
libavdevice57. 0.101 / 57. 0.101
libavfilter 6. 46.102 / 6. 46.102
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc54. 0.100 / 54. 0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/Users/StevenLiu/Movies/objectC/facebook.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf55.22.102
description : This File is Created by Easy RealMedia Tools@!
Duration: 02:00:27.85, start: 0.00, bitrate: 893 kb/s
Stream #0:0(und): Video: h264 (High), 1 reference frame (avc1 /
0x31637661), yuv420p, 640x480, 797 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc
(default)
Metadata:
handler_name: VideoHandler
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz,
stereo, fltp, 87 kb/s (default)
Metadata:
handler_name: SoundHandler
[hls @ 0x105012800] Using AVStream.codec to pass codec parameters to muxers
is deprecated, use AVStream.codecpar instead.
Last message repeated 1 times
[mpegts @ 0x10500fa00] muxrate VBR, pcr every 5 pkts, sdt every 2147483647,
pat/pmt every 2147483647 pkts
Output #0, hls, to '.m3u8':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
description : This File is Created by Easy RealMedia Tools@!
encoder : Lavf57.40.101
Stream #0:0(und): Video: h264, 1 reference frame (avc1 / 0x31637661),
yuv420p, 640x480 (0x0), q=2-31, 797 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
(default)
Metadata:
handler_name: VideoHandler
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz,
stereo, 87 kb/s (default)
Metadata:
handler_name: SoundHandler
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
Process 38828 stopped
* thread #1: tid = 0x114ff0, 0x000100204170
ffmpeg_g`mpegts_check_bitstream(s=0x00010500fa00,
pkt=0x7fff5fbfada0) at mpegtsenc.c:1786, queue =
'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x000100204170
ffmpeg_g`mpegts_check_bitstream(s=0x00010500fa00,
pkt=0x7fff5fbfada0) at mpegtsenc.c:1786
1783 static int mpegts_check_bitstream(struct AVFormatContext *s, const
AVPacket *pkt)
1784 {
1785 int ret = 1;
-> 1786 AVStream *st = s->streams[pkt->stream_index];
1787
1788 if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
1789 if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
(lldb) bt
* thread #1: tid = 0x114ff0, 0x000100204170
ffmpeg_g`mpegts_check_bitstream(s=0x00010500fa00,
pkt=0x7fff5fbfada0) at mpegtsenc.c:1786, queue =
'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x000100204170
ffmpeg_g`mpegts_check_bitstream(s=0x00010500fa00,
pkt=0x7fff5fbfada0) at mpegtsenc.c:1786
frame #1: 0x0001001ad9c0
ffmpeg_g`hls_check_bitstream(s=0x000105012800, pkt=0x7fff5fbfada0)
+ 48 at hlsenc.c:911
frame #2: 0x00010020a751
ffmpeg_g`av_interleaved_write_frame(s=0x000105012800,
pkt=0x7fff5fbfada0) + 529 at mux.c:1096
frame #3: 0x0001000204de ffmpeg_g`write_frame(s=,
pkt=0x7fff5fbfada0, ost=0x000104b14aa0) + 1694 at ffmpeg.c:762
frame #4: 0x00010001d76a ffmpeg_g`process_input_packet [inlined]
do_streamcopy(ist=, ost=, pkt=) +
7370 at ffmpeg.c:1908
frame #5: 0x00010001d518
ffmpeg_g`process_input_packet(ist=0x000104b13fc0,
pkt=0x7fff5fbfb4f0, no_eof=) + 6776 at ffmpeg.c:2434
frame #6: 0x00010001996f ffmpeg_g`transcode [inlined] process_input
+ 1354 at ffmpeg.c:4020
frame #7: 0x000100019425 ffmpeg_g`transcode [inlined]
transcode_step + 1850 at ffmpeg.c:4108
frame #8: 0x000100018ceb ffmpeg_g`transcode + 17563 at
[FFmpeg-devel] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu wrote: > > > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : >> >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu >> wrote: >> > before patched: >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c copy -f >> > hls -v verbose -y .m3u8 >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg >> > developers >> >> >> The way I see it, the auto bsf from the mpegts muxer should already >> cover this without changes? > > > add the hls_check_bitstream into hls format and call the hls->avf to call > the mpegtsenc's check_bitstream, > don't do this operation, it won't call the mpegtsenc's check_bitstream, > look at the message bellow: > This is the wrong approach to fixing this however, it should be understood first why its not doing this transparently right now. hlsenc uses the mpegts muxer like one would use any other muxer, so why does autobsf not get used? If we understand that, maybe it can be fixed in a more generic way, and not end up in ugly hacks in hlsenc. PS: now to the list as well, please just mail to the list, no need to directly mail anyone. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] how to download specific track data of a m3u8 content?
thanks. Yes, readahead the list is must. but during playback, I found ffmpeg downloads each content of the list -- av_read_frame() returns me each content with different stream_index. I'm expecting av_read_frame() returns me the interested stream only. I haven't found a way to do so; or said, is there ffmpeg interface to specify a dedicate stream (stream_index) to download. i'm looking into hls.c; there is recheck_discard_flags(), seems it is designed to do some policy like this. but I haven't found one top level interface of ffmpeg for it. recheck_discard_flags() is called once only during hls_read_packet() when c->first_packet is set -- this flag is set in hls_read_header() only. 2016-06-28 22:22 GMT+08:00 Steven Liu : > 2016-06-28 14:26 GMT+08:00 aihua zhao : > > > Hi Experts: > > > > I use ffmpeg to parse/demux media content, and created a player basing on > > it. > > > > here is a m3u8 content: > > > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8 > > < > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200 > > > > > there are three video track in it. > > > > I found all video/audio tracks are downloaded during playback, and I can > > switch different track on the fly. > > however, it consumes much bandwidth since all tracks are downloaded. > > > > even when I append bandwidth to the url; still the same result: > > > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200 > > > > Is there any way to download the specified track only to save bandwidth? > > > > thanks > > > > Hi Aihua Zhao, > > If you haven't read the m3u8 file and parse the playlist, and read > the sub m3u8 playlist, how do you get the info of the mpegts? > > So it's must readahead the list and list all of the track for choose. > ___ > 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] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
2016-06-29 7:07 GMT+08:00 Hendrik Leppkes : > On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu > wrote: > > > > > > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : > >> > >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu > >> wrote: > >> > before patched: > >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c > copy -f > >> > hls -v verbose -y .m3u8 > >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg > >> > developers > >> > >> > >> The way I see it, the auto bsf from the mpegts muxer should already > >> cover this without changes? > > > > > > add the hls_check_bitstream into hls format and call the hls->avf to call > > the mpegtsenc's check_bitstream, > > don't do this operation, it won't call the mpegtsenc's check_bitstream, > > look at the message bellow: > > > > This is the wrong approach to fixing this however, it should be > understood first why its not doing this transparently right now. > hlsenc uses the mpegts muxer like one would use any other muxer, so > why does autobsf not get used? > > If we understand that, maybe it can be fixed in a more generic way, > and not end up in ugly hacks in hlsenc. > > PS: now to the list as well, please just mail to the list, no need to > directly mail anyone. > > - Hendrik > Because the m3u8 content the mpegts list, and the list is write by "hls muxer", and the ffmpeg have the work flow call *check_bitstream*, and the AVOutputFormat have the check_bitstream method, so I think add the hls_check_bitstream is the right way. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] how to download specific track data of a m3u8 content?
2016-06-29 8:36 GMT+08:00 aihua zhao : > thanks. > > Yes, readahead the list is must. > but during playback, I found ffmpeg downloads each content of the list > -- av_read_frame() returns me each content with different stream_index. > I'm expecting av_read_frame() returns me the interested stream only. > I haven't found a way to do so; or said, is there ffmpeg interface to > specify a dedicate stream (stream_index) to download. > > i'm looking into hls.c; there is recheck_discard_flags(), seems it is > designed to do some policy like this. > but I haven't found one top level interface of ffmpeg for it. > recheck_discard_flags() is called once only during hls_read_packet() when > c->first_packet is set -- this flag is set in hls_read_header() only. > > > 2016-06-28 22:22 GMT+08:00 Steven Liu : > > > 2016-06-28 14:26 GMT+08:00 aihua zhao : > > > > > Hi Experts: > > > > > > I use ffmpeg to parse/demux media content, and created a player basing > on > > > it. > > > > > > here is a m3u8 content: > > > > > > > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8 > > > < > > > > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200 > > > > > > > there are three video track in it. > > > > > > I found all video/audio tracks are downloaded during playback, and I > can > > > switch different track on the fly. > > > however, it consumes much bandwidth since all tracks are downloaded. > > > > > > even when I append bandwidth to the url; still the same result: > > > > > > > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200 > > > > > > Is there any way to download the specified track only to save > bandwidth? > > > > > > thanks > > > > > > > Hi Aihua Zhao, > > > > If you haven't read the m3u8 file and parse the playlist, and read > > the sub m3u8 playlist, how do you get the info of the mpegts? > > > > So it's must readahead the list and list all of the track for > choose. > you mean the function looks like "stream_cycle_channel" in ffplay? > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
On Tue, Jun 28, 2016 at 09:23:14AM +0200, Benoit Fouet wrote:
> Hi,
>
> On 27/06/2016 18:31, Michael Niedermayer wrote:
> >On Mon, Jun 27, 2016 at 02:38:50PM +0200, Benoit Fouet wrote:
> >> h264_ps.c | 11 +++
> >> 1 file changed, 7 insertions(+), 4 deletions(-)
> >>ea8cc471972e1dbaa4f4f03cd7a5fe92a3b848e9
> >>0001-h264_ps-change-decode_scaling_matrices-so-that-it-ta.patch
> >> From c2606da98ecd04762305734f4f45ca8eaf266459 Mon Sep 17 00:00:00 2001
> >>From: Benoit Fouet
> >>Date: Mon, 27 Jun 2016 12:00:39 +0200
> >>Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it
> >>takes
> >> const {s,p}ps
> >>
> >>In order to be able to make SPS const in H264ParamSets,
> >>modify decode_scaling_matrices so that it returns if the scaling
> >>matrix are present in the SPS, instead of altering the input SPS
> >>structure.
> >>---
> >> libavcodec/h264_ps.c | 11 +++
> >> 1 file changed, 7 insertions(+), 4 deletions(-)
> >please document the return value
> >LGTM otherwise
>
> See if attached patch is OK in that regard.
>
> Thanks,
>
> --
> Ben
>
> h264_ps.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
> 29b79e7890da03a59c4742e196ab018337950685
> 0001-h264_ps-change-decode_scaling_matrices-so-that-it-ta.patch
> From 67e714cbdabcb9ed808e8b10c70bbdf670cf3c2d Mon Sep 17 00:00:00 2001
> From: Benoit Fouet
> Date: Mon, 27 Jun 2016 12:00:39 +0200
> Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
> const {s,p}ps
>
> In order to be able to make SPS const in H264ParamSets,
> modify decode_scaling_matrices so that it returns if the scaling
> matrix are present in the SPS, instead of altering the input SPS
> structure.
> ---
> libavcodec/h264_ps.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
LGTM
thx
[...]
--
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 02/13] lavf: update auto-bsf to new BSF API
On Tue, Jun 28, 2016 at 01:33:13PM +0200, Nicolas George wrote: > Le primidi 11 messidor, an CCXXIV, Nicolas George a écrit : > > Well, looking at the code, I am thinking that the current design is flawed: > > the extra alloc in ff_bsf_get_packet() seems completely useless, and could > > be removed as is without any other change in the current code, because all > > current filters are 1:1, it would be different for future 1:N filters. Maybe > > implementing ff_bsf_peek_packet() and using it to replace > > ff_bsf_get_packet() in 1:1 cases would do the trick. > > I have checked that the following quick-and-dirty changes pass FATE. Making > it in shape (testing filters not covered by FATE, making future-proof) would > take time that I would like to spend on lavfi right now. But it proves the > overhead can be reduced easily. applying only the attached patch causes ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -vbsf noise file.avi to [mpeg4 @ 0x25c60a0] Failed to open bitstream filter noise for stream 0 with codec mpeg4: Resource temporarily unavailable [mpeg4 @ 0x25c60a0] Failed to open bitstream filter noise for stream 0 with codec mpeg4: Resource temporarily unavailable [mpeg4 @ 0x25c60a0] Failed to open bitstream filter noise for stream 0 with codec mpeg4: Resource temporarily unavailable [mpeg4 @ 0x25c60a0] Failed to open bitstream filter noise for stream 0 with codec mpeg4: Resource temporarily unavailable [mpeg4 @ 0x25c60a0] Failed to open bitstream filter noise for stream 0 with codec mpeg4: Resource temporarily unavailable [mpeg4 @ 0x25c60a0] Failed to open bitstream filter noise for stream 0 with codec mpeg4: Resource temporarily unavailable [mpeg4 @ 0x25c60a0] Failed to open bitstream filter noise for stream 0 with codec mpeg4: Resource temporarily unavailable [mpeg4 @ 0x25c60a0] Failed to open bitstream filter noise for stream 0 with codec mpeg4: Resource temporarily unavailable Segmentation fault valgrind is also unhappy ==26545== Invalid read of size 8 ==26545==at 0x763535: ff_bsf_get_packet (ffmpeg/ffmpeg_g) ==26545==by 0xAA1653: noise (ffmpeg/ffmpeg_g) ==26545==by 0x7609BB: av_bitstream_filter_filter (ffmpeg/ffmpeg_g) ==26545==by 0x705A4D: av_apply_bitstream_filters (ffmpeg/ffmpeg_g) ==26545==by 0x4B5C68: write_frame (ffmpeg/ffmpeg_g) ==26545==by 0x4B6A42: do_video_out (ffmpeg/ffmpeg_g) ==26545==by 0x4B9D3A: reap_filters (ffmpeg/ffmpeg_g) ==26545==by 0x4BE124: transcode (ffmpeg/ffmpeg_g) ==26545==by 0x4A04D5: main (ffmpeg/ffmpeg_g) ==26545== Address 0x35789af8 is 24 bytes inside a block of size 88 free'd ==26545==at 0x4C2B5D9: free (vg_replace_malloc.c:446) ==26545==by 0xAA16F3: noise (ffmpeg/ffmpeg_g) ==26545==by 0x760954: av_bitstream_filter_filter (ffmpeg/ffmpeg_g) ==26545==by 0x705A4D: av_apply_bitstream_filters (ffmpeg/ffmpeg_g) ==26545==by 0x4B5C68: write_frame (ffmpeg/ffmpeg_g) ==26545==by 0x4B6A42: do_video_out (ffmpeg/ffmpeg_g) ==26545==by 0x4B9D3A: reap_filters (ffmpeg/ffmpeg_g) ==26545==by 0x4BE124: transcode (ffmpeg/ffmpeg_g) ==26545==by 0x4A04D5: main (ffmpeg/ffmpeg_g) ==26545== ==26545== Invalid read of size 4 ==26545==at 0x763548: ff_bsf_get_packet (ffmpeg/ffmpeg_g) ==26545==by 0xAA1653: noise (ffmpeg/ffmpeg_g) ==26545==by 0x7609BB: av_bitstream_filter_filter (ffmpeg/ffmpeg_g) ==26545==by 0x705A4D: av_apply_bitstream_filters (ffmpeg/ffmpeg_g) ==26545==by 0x4B5C68: write_frame (ffmpeg/ffmpeg_g) ==26545==by 0x4B6A42: do_video_out (ffmpeg/ffmpeg_g) ==26545==by 0x4B9D3A: reap_filters (ffmpeg/ffmpeg_g) ==26545==by 0x4BE124: transcode (ffmpeg/ffmpeg_g) ==26545==by 0x4A04D5: main (ffmpeg/ffmpeg_g) ==26545== Address 0x35789b18 is 56 bytes inside a block of size 88 free'd ==26545==at 0x4C2B5D9: free (vg_replace_malloc.c:446) ==26545==by 0xAA16F3: noise (ffmpeg/ffmpeg_g) ==26545==by 0x760954: av_bitstream_filter_filter (ffmpeg/ffmpeg_g) ==26545==by 0x705A4D: av_apply_bitstream_filters (ffmpeg/ffmpeg_g) ==26545==by 0x4B5C68: write_frame (ffmpeg/ffmpeg_g) ==26545==by 0x4B6A42: do_video_out (ffmpeg/ffmpeg_g) ==26545==by 0x4B9D3A: reap_filters (ffmpeg/ffmpeg_g) ==26545==by 0x4BE124: transcode (ffmpeg/ffmpeg_g) ==26545==by 0x4A04D5: main (ffmpeg/ffmpeg_g) ==26545== frame=1 fps=0.0 q=3.5 Lsize= 24kB time=00:00:00.04 bitrate=4899.6kbits/s speed=0.0532x video:13kB audio:1kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 70.148628% ==26545== Invalid read of size 4 ==26545==at 0x7532B2: av_packet_free (ffmpeg/ffmpeg_g) ==26545==by 0x7631D1: av_bsf_free (ffmpeg/ffmpeg_g) ==26545==by 0x7608A0: av_bitstream_filter_close (ffmpeg/ffmpeg_g) ==26545==by 0x4BC99B: ffmpeg_cleanup (ffmpeg/ffmpeg_g) ==26545==by 0x4A18C0: exit_program (ffmpeg/ffmpeg_g) ==26545==by 0x4A0555: main (ffmpeg/ffmpeg_g) ==26545== Address 0x35789b18 is 56 bytes inside a block of size 88 free'd ==26545==at 0x4C2B5D9: free (
[FFmpeg-devel] how to parse audio/video information for rtmp protocal
Hi, FFmpeg has its native rtmp plugin, and also can use rtmpdump instead if enable-librtmp is chosen when building ffmpeg. I have reviewed rtmp specification, where client and server can notify its peer of audio/video information via metadata message, and of audio/video codec via connect command. For live-streamming application, what is the common way to get audio/video information, such as bit rate, audio channel number, sample rate, and frame rate? Are there some ffmpeg functions to get those information? Thanks! Regards Andrew ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] H264ParamSets: make sps const
Hi, On 27/06/2016 14:37, Benoit Fouet wrote: Hi, First patch change decode_scaling_matrices function, so that it does not affect the SPS structure it gets, and marks SPS and PPS const in its arguments. Second patch straightens the check for macroblock sizes in ff_h264_decode_seq_parameter_set and removes the unneeded check in H.264 slice init_dimensions. Last patch make SPS const in H264ParamSets and fixes its usages. I'll apply the patchset in a day or two, if there is no more feedback. Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
