Re: [libav-devel] Importing GIF encoder from ffmpeg
On 07/05/14 00:37, Alessandro Ghedini wrote:
> Hi,
>
> I've been working on merging the GIF encoder from ffmpeg, since libav's
> doesn't
> seem to work very well (in my tests anyway), and my initial approach has been
> to
> simply copy/paste lavc/gif.{c,h} and lavf/gif.c, make them compile and see how
> it goes (I'm using libav.git).
>
> While I've been able to compile the whole thing (with a little bit of work,
> due
> to missing av_copy_packet() and ff_alloc_packet2()),
av_copy_packet in a muxer sounds strange, in libav we do not have such
function since avpackets are refcounted.
ff_alloc_packet2 from what I can recall keeps 1 packet cache in
avcodeccontext, but then if you always copy/duplicate the avpacket
produced it gets a little pointless having it, even worse if you have mt
encoders.
> I'm still having problems apparently related to pixel formats.
Today I'll be traveling so I might look at it when flying to Berlin,
thanks a lot for your effort =)
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] Importing GIF encoder from ffmpeg
Hi,
I've been working on merging the GIF encoder from ffmpeg, since libav's doesn't
seem to work very well (in my tests anyway), and my initial approach has been to
simply copy/paste lavc/gif.{c,h} and lavf/gif.c, make them compile and see how
it goes (I'm using libav.git).
While I've been able to compile the whole thing (with a little bit of work, due
to missing av_copy_packet() and ff_alloc_packet2()), I'm still having problems
apparently related to pixel formats.
Basically, when I'm using ffmpeg (ffmpeg -i test.mkv test.ffmpeg.gif) it selects
"bgr8" and everything goes fine.
> Output #0, gif, to 'test.ffmpeg.gif':
> Stream #0:0: Video: gif, bgr8, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200
> kb/s, 100 tbn, 30 tbc
but when I use avconv, it selects "gray" (which is not what I want):
> Output #0, gif, to 'test.libav.gif':
> Stream #0.0: Video: gif, gray, 1920x1080 [PAR 1:1 DAR 16:9], q=2-31, 200
> kb/s, 100 tbn, 1k tbc
and if I use "-pix_fmt bgr8" the output image is broken.
Compare [0] generated with ffmpeg, and [1] genenerated with "improved" avconv.
I've also tried copying lavu/pixdesc.{c,h} too, but nothing changed, and it
happens with all the other input files I've tried, so it shouldn't be specific
to the input file used.
Does anyone have an idea of what may be causing this? (e.g. if there's a special
avconv option I have to use, or if it is a bug in the gif encoder or in other
parts of libav).
If you want to test this I've setup a fork of libav.git at [2] with my WIP
patches (they still need to be split in proper commits) in the "gif" branch.
Cheers
[0] http://www.ghedini.me/gif_test/test.ffmpeg.gif
[1] http://www.ghedini.me/gif_test/test.libav.gif
[2] https://github.com/ghedo/libav/tree/gif
signature.asc
Description: Digital signature
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] dca: Convert dca_dmixtable to integers
On 06 May 2014, at 09:41, Niels Möller wrote: > Also include zero in the table, eliminating a special case in the > decoder. > > Signed-off-by: Niels Möller > --- > This is a small step towards integer decoding, needed for other work on > 7.1 xll. I think it's fairly safe. Passes make fate-dts (any other easy > regression testing I can do?). Since Anton never re-introduced the FATE DTS downmix tests (he had a patch for it, but it seems to have been delayed and then forgotten), AFAIK fate-dts tests nothing affected by the patch. You should perhaps test DTS to PCM with stereo downmix enabled (-request_channel_layout 3), maybe via the framecrc muxer? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] dca xll: Working audio
ni...@lysator.liu.se (Niels Möller) writes: > I'm now looking at the "Master Audio 7.1.dts" file. There are 5.1 core > channels, and the xll extension has two channel sets. > > Channel set 0 contain 6 residual channels, and from the channel mask, > these are, in order, C, L, R, LFE1, Lss, Rss (surround side). > > Channel set 1 contain 2 non-residual channels, Lsr, Rsr (surround rear). > And it has the downmix coefficients, and the BHierChSet flag set. Implemented this now, mostly as described in previous mail. For residual channels, also the core channels need to be scaled. For now, that's no problem, because I do one channel set at a time, and by the time I get to chset 1 which implies an inverse downmix, core and residual are already added together for the first channel set. It seems to give reasonable output for the "Master Audio 7.1.dts" file, except that the LFE channel is messed up in some places. I had to add a couple of additional hacks for channel order, and I also had to implement "fixed prediction", since that was used for one of the frames in this file. Available at my wip repo as usual. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: add AVFMT_FLAG_BITEXACT.
On Thu, 1 May 2014, Anton Khirnov wrote: Use it instead of checking CODEC_FLAG_BITEXACT in the first stream's codec context. Using codec options inside lavf is fragile and can easily break when the muxing codec context is not the encoding context. --- As general concept, this looks good, thanks! Since this flad is pretty much testing-only, I don't see much point in preserving compatiblity here. Though if someone thinks it's important, I can add a compat wrapper. I'm a little undecided whether it's necessary or not. The safe thing would obviously be to add a compat wrapper. OTOH, no matter how much we advertise the fact that it's only a transition period, people will ignore it and complain later when the compat wrapper is removed. // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support alternative slist parameter in rtmp URLs
On Mon, 5 May 2014, Uwe L. Korn wrote:
Support the URL scheme where the playpath is in an RTMP URL is
passed as the slist argument and the app is given infront of the
query part of the URL:
rtmp://host[:port]/[app]?slist=[playpath]
(other arguments in the query part are stripped as they are not used)
---
libavformat/rtmpproto.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index 8d8aabc..2962737 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2382,7 +2382,7 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags)
{
RTMPContext *rt = s->priv_data;
char proto[8], hostname[256], path[1024], auth[100], *fname;
-char *old_app;
+char *old_app, *qmark, fname_buffer[1024];
uint8_t buf[2048];
int port;
AVDictionary *opts = NULL;
@@ -2480,7 +2480,19 @@ reconnect:
}
//extract "app" part from path
-if (!strncmp(path, "/ondemand/", 10)) {
+qmark = strchr(path, '?');
+if (qmark && strstr(qmark, "slist=")) {
+char* amp;
+// After slist we have the playpath, before the params, the app
+av_strlcpy(rt->app, path + 1, qmark - path);
+fname = strstr(path, "slist=") + 6;
+// Strip any further query parameters from fname
+amp = strchr(fname, '&');
+if (amp) {
+av_strlcpy(fname_buffer, fname, amp - fname + 1);
+fname = fname_buffer;
+}
+} else if (!strncmp(path, "/ondemand/", 10)) {
fname = path + 10;
memcpy(rt->app, "ondemand", 9);
} else {
--
1.9.2
Looks ok to me, will push in a while unless there's objections.
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] dca: Convert dca_dmixtable to integers
Also include zero in the table, eliminating a special case in the
decoder.
Signed-off-by: Niels Möller
---
This is a small step towards integer decoding, needed for other work on
7.1 xll. I think it's fairly safe. Passes make fate-dts (any other easy
regression testing I can do?). Also has the nice effect of shrinking the
table from 964 to 484 bytes. The table values are copied from the spec
(thanks pdf2txt), not derived from the earlier float values.
libavcodec/dcadata.h | 64 ++--
libavcodec/dcadec.c | 19
2 files changed, 42 insertions(+), 41 deletions(-)
diff --git a/libavcodec/dcadata.h b/libavcodec/dcadata.h
index da3422e..28c40cf 100644
--- a/libavcodec/dcadata.h
+++ b/libavcodec/dcadata.h
@@ -7520,38 +7520,38 @@ DECLARE_ALIGNED(16, static const float, lfe_fir_128)[] =
* 2) [-29.750 to -15] with resolution of 0.250 dB
* 3) [-14.875 to 0] with resolution of 0.125 dB
*/
-static const float dca_dmixtable[241] = {
-0.001000, 0.001059, 0.001122, 0.001189, 0.001259, 0.001334, 0.001413,
0.001496,
-0.001585, 0.001679, 0.001778, 0.001884, 0.001995, 0.002113, 0.002239,
0.002371,
-0.002512, 0.002661, 0.002818, 0.002985, 0.003162, 0.003350, 0.003548,
0.003758,
-0.003981, 0.004217, 0.004467, 0.004732, 0.005012, 0.005309, 0.005623,
0.005957,
-0.006310, 0.006683, 0.007079, 0.007499, 0.007943, 0.008414, 0.008913,
0.009441,
-0.01, 0.010593, 0.011220, 0.011885, 0.012589, 0.013335, 0.014125,
0.014962,
-0.015849, 0.016788, 0.017783, 0.018836, 0.019953, 0.021135, 0.022387,
0.023714,
-0.025119, 0.026607, 0.028184, 0.029854, 0.031623, 0.032546, 0.033497,
0.034475,
-0.035481, 0.036517, 0.037584, 0.038681, 0.039811, 0.040973, 0.042170,
0.043401,
-0.044668, 0.045973, 0.047315, 0.048697, 0.050119, 0.051582, 0.053088,
0.054639,
-0.056234, 0.057876, 0.059566, 0.061306, 0.063096, 0.064938, 0.066834,
0.068786,
-0.070795, 0.072862, 0.074989, 0.077179, 0.079433, 0.081752, 0.084140,
0.086596,
-0.089125, 0.091728, 0.094406, 0.097163, 0.10, 0.102920, 0.105925,
0.109018,
-0.112202, 0.115478, 0.118850, 0.122321, 0.125893, 0.129569, 0.133352,
0.137246,
-0.141254, 0.145378, 0.149624, 0.153993, 0.158489, 0.163117, 0.167880,
0.172783,
-0.177828, 0.180406, 0.183021, 0.185674, 0.188365, 0.191095, 0.193865,
0.196675,
-0.199526, 0.202418, 0.205353, 0.208329, 0.211349, 0.214412, 0.217520,
0.220673,
-0.223872, 0.227117, 0.230409, 0.233749, 0.237137, 0.240575, 0.244062,
0.247600,
-0.251189, 0.254830, 0.258523, 0.262271, 0.266073, 0.269929, 0.273842,
0.277811,
-0.281838, 0.285924, 0.290068, 0.294273, 0.298538, 0.302866, 0.307256,
0.311709,
-0.316228, 0.320812, 0.325462, 0.330179, 0.334965, 0.339821, 0.344747,
0.349744,
-0.354813, 0.359956, 0.365174, 0.370467, 0.375837, 0.381285, 0.386812,
0.392419,
-0.398107, 0.403878, 0.409732, 0.415671, 0.421697, 0.427809, 0.434010,
0.440301,
-0.446684, 0.453158, 0.459727, 0.466391, 0.473151, 0.480010, 0.486968,
0.494026,
-0.501187, 0.508452, 0.515822, 0.523299, 0.530884, 0.538580, 0.546387,
0.554307,
-0.562341, 0.570493, 0.578762, 0.587151, 0.595662, 0.604296, 0.613056,
0.621942,
-0.630957, 0.640103, 0.649382, 0.658795, 0.668344, 0.678032, 0.687860,
0.697831,
-0.707107, 0.718208, 0.728618, 0.739180, 0.749894, 0.760764, 0.771792,
0.782979,
-0.794328, 0.805842, 0.817523, 0.829373, 0.841395, 0.853591, 0.865964,
0.878517,
-0.891251, 0.904170, 0.917276, 0.930572, 0.944061, 0.957745, 0.971628,
0.985712,
-1.00,
+static const uint16_t dca_dmixtable[242] = {
+0, 33,35,37,39,41,44,46,
+49,52,55,58,62,65,69,73,
+78,82,87,92,98,104, 110, 116,
+123, 130, 138, 146, 155, 164, 174, 184,
+195, 207, 219, 232, 246, 260, 276, 292,
+309, 328, 347, 368, 389, 413, 437, 463,
+490, 519, 550, 583, 617, 654, 693, 734,
+777, 823, 872, 924, 978, 1036, 1066, 1098,
+1130, 1163, 1197, 1232, 1268, 1305, 1343, 1382,
+1422, 1464, 1506, 1550, 1596, 1642, 1690, 1740,
+1790, 1843, 1896, 1952, 2009, 2068, 2128, 2190,
+2254, 2320, 2388, 2457, 2529, 2603, 2679, 2757,
+2838, 2920, 3006, 3093, 3184, 3277, 3372, 3471,
+3572, 3677, 3784, 3894, 4008, 4125, 4246, 4370,
+4497, 4629, 4764, 4903, 5046, 5193, 5345, 5501,
+5662, 5827, 5912, 5997, 6084, 6172, 6262, 6353,
+6445, 6538, 6633, 6729, 6827, 6925, 7026, 7128,
+7231, 7336, 7442, 7550, 7659, 7771, 7883, 7997,
+8113, 8231, 8350, 8471, 8594, 8719, 8845, 8973,
+9103, 9235, 9369, 9505, 9643, 9783, 9924, 10068,
+10214, 10362, 10512, 10665, 10819, 10976, 11135, 11297,
+11460, 11627, 11795, 11966, 12139, 12315, 12494, 12675,
+12859, 13045, 13234, 13426, 1
