[Ffmpeg-devel-irc] ffmpeg-devel.log.20121012

burek burek021 at gmail.com
Sat Oct 13 02:05:02 CEST 2012


[00:26] <cone-308> ffmpeg.git 03Michael Niedermayer 0759cbedfc3df3: update_initial_timestamps: increase pts_buffer size * 03http://tinyurl.com/9tgnybs03
[00:26] <cone-308> ffmpeg.git 03Michael Niedermayer 071b5069aa41ce: sanm: fix off by 1 error in draw_glyph() * 03http://tinyurl.com/9v79elq03
[00:26] <cone-308> ffmpeg.git 03Michael Niedermayer 070c6b9b9fe5ed: rtspdec:read_line: fix use of uninitialized byte * 03http://tinyurl.com/9bgha6g03
[00:26] <cone-308> ffmpeg.git 03Michael Niedermayer 07e0909ff1584d: lavc: Fix use of uninitialized field. * 03http://tinyurl.com/9m3lszg03
[00:38] <ubitux> i'm trying to understand something in lavf
[00:38] <ubitux> in the swf demuxer, when reading packets, an audio stream can be found
[00:38] <ubitux> need_parsing is set to AVSTREAM_PARSE_FULL
[00:39] <ubitux> then i guess the decoder is supposed to set the sample format on its own
[00:39] <ubitux> it's for example the case for lavc/pcm
[00:39] <ubitux> it appears that it doesn't seem to work as expected
[00:39] <ubitux> ’ "[swf @ 0x2b0a240] Could not find codec parameters for stream 0 (Audio: pcm_s16le, 5512 Hz, 1 channels, 88 kb/s): unspecified sample format"
[00:39] <ubitux> any idea what could cause this?
[00:48] <Compn> does resample have support for 5512hz ?
[00:49] <Compn> or the swf demuxer i guess
[00:49] <Compn> is what that message is from
[00:50] <ubitux> ah you think that's the issue?
[00:53] <michaelni> ubitux, you might want to look at "[PATCH] Parse DEFINESOUND tags in swf" its maybe related
[00:55] <ubitux> oh that's pretty recent.
[00:57] <ubitux> oh awesome
[00:57] <ubitux> that's exactly my problem
[01:06] <ubitux> the patch works fine
[01:32] <ubitux> what's the AV_PIX_FMT for rgb 15-bit?
[01:32] <ubitux> (if any)
[01:53] <Daemon404> ubitux, wouldnt it be rgb555
[01:56] <ubitux> comment say 16 bits so dunno
[02:18] <michaelni> rgb555 is stored in 16bits, 1 bit unused
[02:21] <cone-308> ffmpeg.git 03Michael Niedermayer 075e689b65ce9c: dv: zero dsp before init, this fixes use of uninitialized dct_bits * 03http://tinyurl.com/8rdgfw603
[02:21] <cone-308> ffmpeg.git 03Michael Niedermayer 07e576105d841c: motion-test: zero dsp context * 03http://tinyurl.com/8o4kolg03
[02:21] <cone-308> ffmpeg.git 03Michael Niedermayer 075a75924dfd43: rtmpproto: fix out of array write * 03http://tinyurl.com/8zwshom03
[02:27] Action: Daemon404 pokes bcoudurier to OK his fate key
[04:26] <cone-308> ffmpeg.git 03Michael Niedermayer 07927d866a9961: tscc2: fix out of array access * 03http://tinyurl.com/8ql5okd03
[04:26] <cone-308> ffmpeg.git 03Michael Niedermayer 0762722ae2d4b2: nellymoserenc: fix array element ordering * 03http://tinyurl.com/96gj8sv03
[04:29] <Compn> Daemon404 : email him
[04:30] <Daemon404> uh
[04:30] <Daemon404> thats kinda what i did
[04:30] <Daemon404> >fate-admin email
[04:30] <Daemon404> as seen on fate.html
[04:30] <Compn> maybe it went to spam :P
[04:30] <Daemon404> no
[04:30] <Daemon404> michaelni confirmed reception
[04:30] <Compn> ok
[04:30] <Daemon404> but only bcoudurier can add the key.
[06:19] <bcoudurier> sowy
[06:36] <ohsix> arch name matches *arch* -> test failure :>
[08:22] <j-b> burek: nope
[09:26] <durandal_1707> omg, i just found source of old bug
[09:32] Action: ubitux is wondering why zlib's uncompress never works while a manual zstream with only inflate Z_FINISH with the same buffer sizes just works
[09:32] Action: ubitux really hates this lib
[09:33] <durandal_1707> ubitux: what is using zlib?
[09:34] <ubitux> ffmpeg
[09:34] <ubitux> do you have an alternative? :)
[09:34] <durandal_1707> i mean where it is failing?
[09:35] <ubitux> i'm writing some code to support zlib compressed raw images in swf
[09:35] <ubitux> basically i've in and out len, i allocate the buffers, copy the data
[09:35] <ubitux> uncompress() fails (-5)
[09:35] <ubitux> one manual inflate just works without any problem
[09:36] <ubitux> but manual inflat is 50 lines instead of 1
[09:39] <durandal_1707> -5 beans buffer is too small
[09:39] <durandal_1707> s/beans/means
[09:41] <ubitux> yes but i put a huge one and it didn't help
[09:42] <durandal_1707> why you copy data?
[09:42] <durandal_1707> how is image data stored in container?
[09:43] <ubitux> i can avoid the copy, it's just temporary
[09:44] <ubitux> the image is just a raw image zlib compressed
[09:44] <durandal_1707> continous?
[09:45] <ubitux> http://pastie.org/5039931
[09:46] <ubitux> durandal_1707: well there is a palette, and then the data, in my case
[09:46] <ubitux> but it's not really the issue here :p
[09:52] <durandal_1707> ubitux: you set out_len ?
[09:53] <ubitux> yes
[09:53] <durandal_1707> and using cast for out_len is bad idea
[09:53] <durandal_1707> make out_len unsigned long
[09:54] <ubitux> that was just copied from another code in ffmpeg, i should change it yes
[09:54] <divVerent> 09:35:56        @ubitux | one manual inflate just works without any problem
[09:54] <divVerent> 09:36:17        @ubitux | but manual inflat is 50 lines instead of 1
[09:54] <divVerent> ubitux: really?
[09:55] <divVerent> it's shorter than that in the DarkPlaces engine ;)
[09:55] <durandal_1707> ubitux: is see no cast in ffmpeg code whice use uncompress
[10:03] <ubitux> libavformat/mov.c:    if (uncompress (moov_data, (uLongf *) &moov_len, (const Bytef *)cmov_data, cmov_len) != Z_OK)
[10:05] <durandal_1707> moov_len is long so it is less wrong but still wrong
[10:06] <durandal_1707> but i do not think anything bad will happen if moov_len is negative
[10:07] <ubitux> oh
[10:07] <ubitux> that was the problem
[10:07] <ubitux> thx durandal_1707 :)
[10:08] <durandal_1707> see, casts are dangerous!
[10:08] <ubitux> yes :(
[10:09] <divVerent> they're more fun on big endian platforms ;)
[10:49] <ubitux> [~/src/ff/ffmpeg]% grep -m 1 pal libavformat/avidec.c
[10:49] <ubitux>     uint32_t pal[256];
[10:49] <ubitux> [~/src/ff/ffmpeg]% grep 'memcpy.*pal' libavformat/avidec.c
[10:49] <ubitux>                 memcpy(pal, ast->pal, AVPALETTE_SIZE);
[10:49] <ubitux> [~/src/ff/ffmpeg]% git grep 'define.*AVPALETTE_SIZE'
[10:49] <ubitux> libavutil/pixfmt.h:#define AVPALETTE_SIZE 1024
[10:49] <ubitux> is this really ok?
[10:49] <ubitux> oh, forget it.
[10:49] <ubitux> i'm stupid.
[10:52] Action: ubitux hates himself
[11:28] <cone-741> ffmpeg.git 03Paul B Mahol 0756519d7d14ac: takdec: s/bits_per_coded_sample/bits_per_raw_sample * 03http://tinyurl.com/8zjch4703
[11:28] <cone-741> ffmpeg.git 03Paul B Mahol 074dcf71aacca6: takdec: stop decoding in case of unknown bps * 03http://tinyurl.com/8k9vue503
[11:44] <ubitux> yepee, added locally support for 500+ swf samples.
[11:46] <divVerent> ubitux: can you explain why av_x_if_null is a good idea to have especially as a function, not as a macro?
[11:46] <divVerent> it silently loses type info...
[11:46] <ubitux> calling function
[11:46] <divVerent> so you can have a foo*f, and do bar *b = av_x_if_null(f, "argh");
[11:46] <ubitux> av_x(char *)av_x_if_null(av_get_sample_fmt_name(outlink->format), "?"),
[11:47] <divVerent> and it'll compile without warning
[11:47] <divVerent> yes, what I dislike here is the lack of any warning on an error
[11:47] <ubitux> libavfilter/avfilter.c:               src->name, srcpad, (char *)av_x_if_null(av_get_media_type_string(src->output_pads[srcpad].type), "?"),
[11:47] <divVerent> a macro would solve this better, but unfortunately evaluate its arg twice
[11:47] <ubitux> etc.
[11:47] <ubitux> yes, that was the point
[11:47] <ubitux> we could have both
[11:47] <divVerent> wonder if it'd be wiser to have the function next to a gcc specific macro
[11:47] <divVerent> (foo ?: bar) actually does the same as the function :P
[11:48] <divVerent> so in GNUC it could use the ?: operator in a macro evaluating everything only once
[11:48] <ubitux> just add the macro version :)
[11:48] <ubitux> (generic one, not gnuc)
[11:48] <divVerent> but that one evaluates twice, and is slow ;)
[11:48] <divVerent> which is kind of the point of the function to avoid it
[11:48] <ubitux> yes, but when it's not a function you can use the macro :p
[11:49] <divVerent> I suppose what you REALLY wanted was template<class T> inline T av_x_if_null(T x, T y) { return x ? x : y; }
[11:49] <divVerent> but C unfortunately lacks templates :P
[11:49] <ubitux> "unfortunately"
[11:49] <ubitux> :)
[11:49] <durandal_1707> *fortunately
[11:49] <divVerent> actually... didn't C11 solve this even?
[11:50] <divVerent> no, not really, damn
[11:50] <divVerent> or Perl's interpretation of the || and && operators would help here
[11:50] <divVerent> i.e. not a "0 or 1" result, but "the last one evaluated is the result"
[11:51] <divVerent> at least a C11 type-generic expression could be used to special case the function for void * and const void *
[12:04] <divVerent> and a C89 hack actually allows comparing sizeof() of the types :P
[12:08] <j-b> bcoudurier ?
[12:21] <divVerent> ubitux: some fun hackery ;) https://gist.github.com/3878566
[12:21] <divVerent> but, it doesn't verify the return type, and has the side effect of doing something REALLY bad if the warning occurred
[12:21] <divVerent> also, lacks parentheses, but this hack isn't supposed to be used anyway
[12:21] <divVerent> and is slow
[12:25] <divVerent> ’&&&&&&&’&&&&&&&(void) foo[sizeof(x == y)], \                                    
[12:25] <divVerent> this is actually better, somewhat... ;) (add * 0 after the sizeof)
[12:25] <divVerent> https://gist.github.com/3878585 - better hack
[12:25] <divVerent> sizeof serves to prevent the compare from actually being executed no matter how dumb the compiler is
[13:33] <ubitux> divVerent: erk :)
[13:35] <Tjoppen> divVerent: is there a relevant thread on the ml?
[13:35] <divVerent> Tjoppen: no
[13:35] <divVerent> I was just wondering about the possibly dangerous av_x_if_null function
[13:35] <divVerent> dangerous, in the sense that type mistakes aren't noticed by the compiler
[13:36] <divVerent> not as in really broken
[13:36] <divVerent> but I can't find a good constructive solution, it looks like standard C allows nothing beter
[13:36] <divVerent> but GNU C and C++ do
[13:36] <Tjoppen> oh yeah.. why isn't that a macro?
[13:36] <divVerent> because the first arg is usually a function call
[13:37] <divVerent> so evaluating it twice would be bad
[13:37] <divVerent> (bad as in unnecessarily slow, I've not seen it with a function with side effects)
[13:37] <Tjoppen> stick it in a struct or something perhaps?
[13:38] <divVerent> the probably sanest way to do this in C would be to extend the functions that currently may return NULL by a "return this if not found" arg
[13:38] <divVerent> but that'd be a hell of a lot of API changes, as some of these functions are public
[13:38] <Tjoppen> I was just about to suggest a macro that does a check before calling, which is what you pasted
[13:39] <divVerent> yes, but it can't test the return value
[13:39] <divVerent> unless said macro would also do the assigning
[13:39] <divVerent> but that gets ugly then
[13:39] <divVerent> ./libavfilter/graphdump.c:            format = av_x_if_null(av_get_sample_fmt_name(link->format), "?");
[13:39] <divVerent> this is the typical use
[13:40] <divVerent> sure, in this specific case evaluating twice is harmless (just ugly)
[13:41] <divVerent> actually... it looks to me like currently ALL uses of this operate on const char * ;)
[13:41] <divVerent> but if it is to become type specific, it'd get a longer name (like av_x_if_null_const_char) which is ugly too
[13:42] <Tjoppen> can't there be a macro that defines a local function perhaps?
[13:42] <Tjoppen> *static function
[13:42] <Tjoppen> that also takes the type
[13:42] <divVerent> but even then one would have to specify the type explicitly when calling
[13:42] <divVerent> probably pointless, and still error prone
[13:42] <Tjoppen> DECLARE_AV_X_IF_NULL(char)
[13:42] <divVerent> sure, but then you'd need av_x_if_null_char() :P
[13:42] <Tjoppen> not if you only use one version of it in each file :)
[13:42] <divVerent> hehe
[13:43] <divVerent> now that's fun
[13:43] <divVerent> but... probably it should just stay as is
[13:43] <divVerent> it was interesting to think about it, this thing IS harmful, but there isn't really a better solution in C
[13:43] <divVerent> plus, this is a public API already
[13:43] <divVerent> C already contains its own such harmful functions
[13:43] <divVerent> e.g. strchr takes a const char * input string, but suddenly returns a non-const char *
[13:44] <Tjoppen> durr
[13:44] <divVerent> lack of function overloading led to this
[13:45] <Tjoppen> I never asked for this
[13:57] <cone-741> ffmpeg.git 03Paul B Mahol 07caa7e24eb1d4: truemotion2: remove unreachable code * 03http://tinyurl.com/9vbf4ey03
[14:19] <cone-741> ffmpeg.git 03Luca Barbato 0726b3fde6a78f: doc: update the faq entry about custom I/O * 03http://tinyurl.com/8cvmfn603
[14:19] <cone-741> ffmpeg.git 03Martin Storsjö 071093383d6cf7: random_seed: Support using CryptGenRandom on windows * 03http://tinyurl.com/9kml9s803
[14:19] <cone-741> ffmpeg.git 03Diego Biurrun 070a75d1da23b8: options_table: refs option is not snow-only * 03http://tinyurl.com/9cvwwgh03
[14:19] <cone-741> ffmpeg.git 03Michael Niedermayer 0743cce41267a7: Merge commit '0a75d1da23b8659ec49391469bb592da12760077' * 03http://tinyurl.com/99aoosd03
[14:33] <cone-741> ffmpeg.git 03Diego Biurrun 079734b8ba56d0: Move avutil tables only used in libavcodec to libavcodec. * 03http://tinyurl.com/9cafmd403
[14:33] <cone-741> ffmpeg.git 03Michael Niedermayer 07e33565837084: Merge commit '9734b8ba56d05e970c353dfd5baafa43fdb08024' * 03http://tinyurl.com/8djjnr803
[14:41] <cone-741> ffmpeg.git 03Janne Grunau 07e578f8f4680f: prepare 9_beta1 release * 03http://tinyurl.com/95qnzv503
[14:41] <cone-741> ffmpeg.git 03Mans Rullgard 0715ba7f6525c0: parseutils: fix const removal warning * 03http://tinyurl.com/9kqsbj403
[14:41] <cone-741> ffmpeg.git 03Michael Niedermayer 07d6135a886d85: Merge commit '15ba7f6525c0f56f0c8e3e3e0c0c5129de054f41' * 03http://tinyurl.com/9aa8go803
[14:43] <durandal_1707> michaelni_: is CID 700222 irrelvant?
[14:54] <burek> how can I ask for a change in http://ffmpeg.org/download.html
[14:54] <michaelni_> durandal_1707, i dont know
[14:55] <michaelni_> burek, patch or pull request
[14:55] <burek> i would like to add the 'id' to all those <h2> sections, so that they can be easily accessed by http://ffmpeg.org/download.html#some_id
[14:55] <burek> hm, let me see if I can create my first patch :D
[14:56] <ubitux> (lots of swf improvements incoming tonight!)
[14:57] <michaelni_> burek, git patch against git://ffmpeg.org/ffmpeg-web is absolutely needed 
[14:57] <michaelni_> dont send a patch of the .html
[14:57] <michaelni_> its not stored that way so we couldnzt apply
[14:57] <burek> is there any url where I can see the source online?
[14:57] <burek> is it on the ffmpeg gitweb already?
[14:58] <michaelni_> localhost after git clone :)
[14:58] <burek> :)
[14:58] <burek> ok :)
[14:58] <burek> let me try
[14:59] <cone-741> ffmpeg.git 03Mans Rullgard 0768e360a83c5b: parseutils-test: various cleanups * 03http://tinyurl.com/8uz3bzt03
[14:59] <cone-741> ffmpeg.git 03Mans Rullgard 07366b72f149a7: svq3: replace unsafe pointer casting with intreadwrite macros * 03http://tinyurl.com/9dkk8d203
[14:59] <cone-741> ffmpeg.git 03Mans Rullgard 07fb32f31af76c: svq3: fix pointer type warning * 03http://tinyurl.com/9lb8zoq03
[14:59] <cone-741> ffmpeg.git 03Martin Storsjö 079a92aea27bad: avutil: Add functions for allocating opaque contexts for algorithms * 03Error03
[14:59] <cone-741> ffmpeg.git 03Martin Storsjö 07e002e3291e6d: Use the new aes/md5/sha/tree allocation functions * 03http://tinyurl.com/8g65syl03
[14:59] <cone-741> ffmpeg.git 03Michael Niedermayer 07f391e405dfde: Merge commit 'e002e3291e6dc7953f843abf56fc14f08f238b21' * 03http://tinyurl.com/8ago2z703
[15:14] <burek> michaelni_ is this correct http://pastebin.com/fAX2Jcx2 :)
[15:27] <michaelni_> burek, its missing commit message and author
[15:28] <michaelni_> git commit -a -s and git format-patch -1 should  help
[15:30] <burek> do i really need to do al that :S
[15:30] <burek> can you put yourself as author and random commit msg? :)
[15:31] <burek> i dont really care about credits and stuff, i just need those ids :)
[15:36] <michaelni_> do i really need to do al that :S
[15:36] <durandal_1707> burek: how that is useful?
[15:37] <durandal_1707> ^patch
[15:39] <cone-741> ffmpeg.git 03Martin Storsjö 07da18e918a4ec: md5: Allocate a normal private context for the opaque md5 context pointer * 03http://tinyurl.com/9fl4fyk03
[15:39] <cone-741> ffmpeg.git 03Mans Rullgard 07fdd666094d42: build: add support for Tru64 (OSF/1) * 03http://tinyurl.com/9ynbqjs03
[15:39] <cone-741> ffmpeg.git 03Anton Khirnov 07d2fcb356caf3: pixdesc: add functions for accessing pixel format descriptors. * 03http://tinyurl.com/8vnas2f03
[15:39] <cone-741> ffmpeg.git 03Anton Khirnov 07b7f1010c8fce: tools: do not use av_pix_fmt_descriptors directly. * 03http://tinyurl.com/8rj5djq03
[15:39] <cone-741> ffmpeg.git 03Michael Niedermayer 07a33ed6bc74b6: Merge commit 'b7f1010c8fce09096057528f7cd29589ea1ae7df' * 03http://tinyurl.com/8n9mtrv03
[15:43] <burek> ok, you're right
[15:54] <durandal_1707> i get "FF_API_PIX_FMT is not defined, evaluates to 0"  spam
[16:09] <cone-741> ffmpeg.git 03Anton Khirnov 070a7068fa5dda: sws: do not use av_pix_fmt_descriptors directly. * 03http://tinyurl.com/9ay69hy03
[16:09] <cone-741> ffmpeg.git 03Anton Khirnov 079953ff3cd844: mpegvideo: fix indentation * 03http://tinyurl.com/97fa62403
[16:09] <cone-741> ffmpeg.git 03Michael Niedermayer 07a9bd51b1e647: Merge commit '9953ff3cd844eb5f6d8dfce98cad94b78a0fc7dc' * 03http://tinyurl.com/965skrm03
[16:27] <cone-741> ffmpeg.git 03Paul B Mahol 073d179edf6d2a: yop: check return value of avformat_new_stream() * 03http://tinyurl.com/8p4czqo03
[16:52] <cone-741> ffmpeg.git 03Anton Khirnov 0750ba57e0ce63: lavc: do not use av_pix_fmt_descriptors directly. * 03http://tinyurl.com/8lkgsea03
[16:52] <cone-741> ffmpeg.git 03Michael Niedermayer 07af7dd79a3230: Merge commit '50ba57e0ce63d9904269ea0728936a0c79f8bfb5' * 03http://tinyurl.com/9o6nfmz03
[17:04] <durandal_1707> michaelni: that av_pix_fmt in lavc thing is incomplete, is there other such stuff left to merge?
[17:07] <michaelni> durandal_1707, you mean the FF_API_PIX_FMT warnings ?
[17:07] <durandal_1707> no, av_pix_... which should now be static....
[17:08] <michaelni> please elaborate what & where
[17:09] <durandal_1707> i think shared build is broken _now_
[17:12] <michaelni> durandal_1707, ok ill look into it once fate tells me what is missing, thx for the vague hints
[17:12] <durandal_1707> michaelni: i can fix this right now
[17:13] <cone-741> ffmpeg.git 03Anton Khirnov 0759ee9f78b0cc: lavfi: do not use av_pix_fmt_descriptors directly. * 03http://tinyurl.com/8rycd7h03
[17:13] <cone-741> ffmpeg.git 03Michael Niedermayer 0713afee951a49: Merge commit '59ee9f78b0cc4fb84ae606fa317d8102ad32a627' * 03http://tinyurl.com/8ztj7qa03
[17:14] <michaelni> durandal_1707, please do, and thanks
[17:17] <ubitux> anyone an app to generate swf? (except ffmpeg)
[17:17] <ubitux> i'd like to ask for a custom sample... :p
[17:18] <divVerent> ubitux: Adobe Flash?
[17:18] <ubitux> for example :p
[17:18] <divVerent> probably that's not what you wanted to hear
[17:18] <ubitux> well i don't want the app :p
[17:18] <divVerent> I don't have it, I just know it exists ;)
[17:18] <ubitux> i'd like someone to generate a sample for me ;)
[17:18] <divVerent> ah, you just accidentally the verb
[17:18] <ubitux> ah indeed
[17:19] <divVerent> community/mtasc 20091229-4
[17:19] <divVerent>     An open source flash (swf) compiler
[17:19] <divVerent> wonder if that would help? wouldn't know what to do with it though
[17:21] <ubitux> i'm looking for a swf with a "lossless bitmap" in rgb 15
[17:21] <ubitux> :p
[17:21] <ubitux> i have 500+ samples with pal8, 30+ samples with rgb24
[17:21] <ubitux> but none with rgb15 :(
[17:22] <divVerent> hm... I have a directory with a bunch of swf files, maybe one of them has it... let me see
[17:24] <cone-741> ffmpeg.git 03Anton Khirnov 0722c8cbc0da8b: lavu,lavd: do not use av_pix_fmt_descriptors directly. * 03http://tinyurl.com/94s5n9703
[17:24] <cone-741> ffmpeg.git 03Michael Niedermayer 0727ccc82e1bb1: Merge remote-tracking branch 'qatar/master' * 03http://tinyurl.com/98ngbvj03
[17:25] <divVerent> damn, swfextract doesn't really show the type
[17:25] <divVerent> it just says "so many PNGs"
[17:26] <divVerent> oh wait... actually
[17:26] <divVerent> [014]     17792 DEFINEBITSLOSSLESS defines id 0020 image 236x180 (8 bpp)
[17:26] <divVerent> this looks greppable
[17:27] <divVerent> no, none match, but I have a way to test
[17:33] <cone-741> ffmpeg.git 03Paul B Mahol 07a51540d81167: lavc: do not use av_pix_fmt_descriptors directly * 03http://tinyurl.com/8kbzk2603
[17:35] <divVerent> swfc only has 16bit support, not 15
[17:40] <cone-741> ffmpeg.git 03Michael Bradshaw 07a41c824c539c: Parse DEFINESOUND tags in swf (fix ticket 1638) * 03http://tinyurl.com/9zbd9be03
[17:40] <ubitux> what is swfc?
[17:40] <ubitux> divVerent: it's likely the same
[17:41] <ubitux> there are 3 cases
[17:41] <ubitux> rgb24 (32 bits actually), pal 8, and the rgb15 (16 bits)
[17:42] <cone-741> ffmpeg.git 03Paul B Mahol 0777e6b085a338: imgutils: do not use av_pix_fmt_descriptors directly * 03http://tinyurl.com/9xa6qs603
[17:44] Action: durandal_1707 this is too much typing
[17:47] <divVerent> ok
[17:48] <divVerent> I also noticed that swfc unfortunately can't generate 16bits, because it only supports png input which has no 16bpp support
[17:48] <divVerent> at least imagemagick can't output such png
[17:56] <divVerent> http://www.mindless-labs.com/samhaxe/doc/1.0/files/src/NsFastXml-hx.html this is what I would try next, but have to go
[17:57] <cone-741> ffmpeg.git 03Heesuk Jung 07e3301459f691: avidec: Use sample size in case incorrect timestamps for aac in AVI (Ticket #1755) * 03http://tinyurl.com/8ob83eh03
[17:58] <cone-741> ffmpeg.git 03Michael Niedermayer 070d002de4a452: exr: fix twin ; * 03http://tinyurl.com/9g8agrv03
[18:01] <durandal_1707> michaelni: where is syntax to mark ;; red in vim?
[18:01] <durandal_1707> i need to write one...
[18:04] <cone-741> ffmpeg.git 03Paul B Mahol 0782eba2266739: lavd: do not use av_pix_fmt_descriptors directly * 03http://tinyurl.com/9ur9haf03
[18:12] <ubitux> durandal_1707: ok :)
[18:13] <durandal_1707> ubitux: np :)
[18:20] <ubitux> michaelni: ok to push "[PATCH 4/4] lavf/swf: rename some tag defines to match the specs." ?
[18:21] <ubitux> philipl: i'm going to make the mov_text share some code with a "raw" text subtitle
[18:21] <ubitux> do you have any objection?
[18:22] <durandal_1707> michaelni: exporting ff_* in lavu is nonsense
[18:24] <michaelni> ubitux, iam not a big fan of renaming things unless theres a maintainer on the ffmpeg side who maintains the specific code
[18:25] <michaelni> it can make merging harder
[18:25] <ubitux> matching the spec looks important in these cases :(
[18:25] <ubitux> (there are not much, and having the "sound" info for instance is useful)
[18:26] <ubitux> but well i won't insist
[18:26] <ubitux> durandal_1707: btw, if you have some swf with nellymoser and/or speex, i'm also interested! :)
[18:26] <michaelni> ubitux, just volunteer as maintainer for swf :)
[18:27] <michaelni> durandal_1707, yes it is
[18:27] <ubitux> michaelni: okay! :)
[18:30] <ubitux> michaelni: what's the procedure? :)
[18:30] <durandal_1707> ubitux: you do merges from libav
[18:31] <ubitux> right, looks safe so far
[18:31] <ubitux> the biggest threat is random file renames
[18:31] <ubitux> michaelni: https://github.com/ubitux/FFmpeg/compare/master...swf-misc
[18:31] <ubitux> i'll soon push up to the N-1 commit
[18:35] <durandal_1707> ubitux: you do _all_ merges
[18:35] <ubitux> sure right..
[18:35] <durandal_1707> not just swf file ....
[18:36] <ubitux> huh?
[18:36] <ubitux> no :(
[18:39] <durandal_1707> michaelni: so is it forbiden making ff_* used outside like in lavfi to be renamed to av_* ? (or this is just cosmetics ?)
[18:51] <michaelni> ubitux, if you want me to merge something, just tell me what
[18:52] <ubitux> ok, give me some time to finish the latest commit then
[18:52] <michaelni> durandal_1707, ff* should not be used from outside, code violating that should be changed
[18:52] <michaelni> existing ff symbols probably should be kept for compatibility until the next major bump
[18:56] <durandal_1707> and what about adding new av_* stuff (which is just ff_* with different name)?
[18:59] <cone-741> ffmpeg.git 03Paul B Mahol 07a291345b1e82: sws: do not use av_pix_fmt_descriptors directly * 03http://tinyurl.com/935tzc903
[19:00] <TimNich> Hmm! 1 second quicktime in 8min 32 sec quicktime out:(
[19:03] <michaelni> durandal_1707, sure can be done, or avpriv_ depending on intended visibility/use
[19:04] <TimNich> 5e6439a12508
[19:07] <TimNich> errr. 047dcfabc bad,  bo2943 probably, what has happened to cut n paste...
[19:11] <michaelni> TimNich, can you elaborate on bad ?
[19:11] <michaelni> how can i reproduce?
[19:12] <cone-741> ffmpeg.git 03Michael Niedermayer 076f557a2e125b: caca: fix 10l typo * 03http://tinyurl.com/8nwzjxh03
[19:13] <durandal_1707> that is damn copy/paste
[19:14] <TimNich> 1 second uncompressed yup mov -> proreHQ, after that comitt comes out with a reported duration in QT of 8:32, but plays for a second, then the counter keeps on counting with a freeze frame. Import into Avid takes 10 mins instead of 5seconds and is rubbish..
[19:16] <TimNich> b02493e476
[19:18] <TimNich> you can see the wrong duration in ffplay too
[19:21] <michaelni> TimNich, i see no  odd duration with tests/data/fate/vsynth1-prores*mov
[19:21] <michaelni> that is with ffplay
[19:22] <TimNich> I will try a simpler command string
[19:25] <TimNich> OK with no vf it is OK
[19:26] <durandal_1707> michaelni: sample aspect ration 0....100... / 0 fails in lavfi , so ffplay cant display image, i think any sample ration with den 0 is invalid
[19:28] <TimNich> sorry wrong file, still get it with a simple command line
[19:30] <TimNich> ffmpeg_bisect -i in.mov -y -f mov -map 0:v -flags +ildct -top 1 -c:v prores -profile:v 3 -an in-gb02493e.mov
[19:32] <TimNich> nitrate is also reported as 119kb/s instead of 64694kb/s
[19:32] <TimNich> s /n/b/ 
[19:40] <michaelni> durandal_1707, 0/0 == nan should not cause problems
[19:41] <durandal_1707> it causes problems with lavfi...
[19:41] <durandal_1707> when using with ffplay
[19:41] <durandal_1707> so instead of adding broken workarounds in decoder lavfi should be fixed
[19:42] <michaelni> TimNich, a 3:07.63 file is still 3:07.60 with that with ffpllay
[19:42] <durandal_1707> one of such workarounds is in dpx
[19:44] <michaelni> dpx checks also for aspect ratio <0 which surely is invalid
[19:44] <TimNich> michaelni: that commit definitely breaks with my source material. my 1 sec is 22M would you like it somewhere?
[19:44] <michaelni> but 0/0 should work like 0/1
[19:45] <michaelni> TimNich, yes, ill look once i have time
[19:47] <TimNich> michaelni: not sure what other info I can provide, my material has a timecode track and is interlaced, that and the bigger frame size and the hq coding are the differences from the fate sample.
[19:52] <michaelni> TimNich, you can provide the / a file that is needed to reproduce it 
[19:55] <TimNich> michaelni: 3 files in uploads.ffmpeg source, script and txt.
[20:00] <TimNich> script  is a bit convoluted as its a general purpose test script, but you get the command line from it.
[20:02] Action: TimNich of home now
[20:13] <michaelni> TimNich, fixed locally, ill push after some tests
[20:13] <burek> michaelni, is there any interest in registering ffmp.eg domain, for future user?
[20:13] <burek> use*
[20:15] <burek> would be useful for fancy short ulrs if needed, dunno
[20:15] <michaelni> burek, feel free to register it if you want ...
[20:26] <cone-741> ffmpeg.git 03Michael Niedermayer 073a48e38ad0e3: motion_est: more complete SAB diamond size check * 03http://tinyurl.com/9ha6grx03
[20:26] <cone-741> ffmpeg.git 03rogerdpack 078684e396563a: add dshow maintainer * 03http://tinyurl.com/9eoadc303
[20:26] <cone-741> ffmpeg.git 03Michael Niedermayer 07b8d64559d5dd: movenc: fix timescale for timecode track * 03http://tinyurl.com/96qjlw403
[20:50] <ubitux> here we go, even more samples supported.
[20:56] <burek> michaelni, ok :) btw, is this better: http://pastebin.com/8eaFv5z9
[21:10] <burek> wait
[21:10] <burek> i did something wrong :/
[21:17] <burek> i hope this one is correct http://pastebin.com/D0sj643f
[21:38] <Daemon404> o my key is approved
[21:39] <Daemon404> ill enable mingw native fate ubuilds, ioc, and maybe inspxe-cl
[21:53] <cone-741> ffmpeg.git 03Clément BSsch 070c40220b9dbc: lavf/swfdec: fix flushing with compressed swf. * 03http://tinyurl.com/8wotkx403
[22:16] <michaelni> burek, patch applied
[22:25] <burek> michaelni great :) thanks :)
[22:53] <cone-741> ffmpeg.git 03Michael Niedermayer 075e885275f1ed: mpeg4videodec: disable frame multithreading for GMC, its not implemented at all * 03http://tinyurl.com/9bhr46b03
[23:11] <cone-741> ffmpeg.git 03Clément BSsch 07cd78192d09d1: lavf/swfdec: return more meaningful error codes. * 03http://tinyurl.com/9regwa903
[23:11] <cone-741> ffmpeg.git 03Clément BSsch 0791fad50f631f: lavf/swf: define more tags. * 03http://tinyurl.com/9vnwg2403
[23:11] <cone-741> ffmpeg.git 03Clément BSsch 07a1d2210debdd: lavf/swf: re-align after previous commit. * 03http://tinyurl.com/9d9ltr903
[23:11] <cone-741> ffmpeg.git 03Clément BSsch 07cdfa92641531: lavf/swf: transform the swf tags define in an enum. * 03http://tinyurl.com/9boczqh03


More information about the Ffmpeg-devel-irc mailing list