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

[burek]

[00:08] <michaelni> saste, setdar works again, thanks!
[00:26] <cone-483> ffmpeg.git 03Clément BSsch 07master:635389ccfa96: Cleanse GIF muxer and encoder.
[00:26] <cone-483> ffmpeg.git 03Clément BSsch 07master:e065e8a4ea5c: lavc/gif: crop image when possible.
[00:27] <cone-483> ffmpeg.git 03Clément BSsch 07master:7b972d82b673: gif: reindent after previous commits.
[00:27] <cone-483> ffmpeg.git 03Clément BSsch 07master:dfb323109c62: lavf/gif: simplify palette writing.
[00:27] <cone-483> ffmpeg.git 03Clément BSsch 07master:71411b69a225: lavc/gif: merge two allocation checks.
[00:27] <cone-483> ffmpeg.git 03Clément BSsch 07master:8694e87127a3: lavc/gif: return more meaningful error code.
[00:31] <ubitux> i see nothing about bytestream vs bytestream2 api
[00:32] <ubitux> is there some doc shadow somewhere?
[00:32] <ubitux> (i'd like to know if it's relevant to move the bytestream code in the gif encoder to the v2 api)
[00:33] <durandal11707> only if it could write out end of buffer
[00:33] <ubitux> there is a check for this
[00:34] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/gif.c;hb=HEAD#l173
[00:34] <ubitux> so potentially interesting?
[00:35] <durandal11707> well it cant hurt, and overhead is small
[00:36] <ubitux> ok
[00:43] <durandal11707> ubitux: so you looked at that thread?
[00:43] <cone-483> ffmpeg.git 03Clément BSsch 07master:91a5b4d480a0: gif: remove outdated comments.
[00:44] <ubitux> durandal11707: quickly
[00:44] <ubitux> but a bunch of people already talked so i guess i'll wait more :)
[00:45] <durandal11707> ubitux: is it bug? or?
[00:45] <ubitux> i don't know
[00:45] <cehoyos> a bug? Where?
[00:45] <ubitux> cehoyos: he's talking about the fieldmatch thread
[00:45] <ubitux> but i was too lazy to have a deep look
[00:46] <cehoyos> I think that is one of the few threads without a bug ;-)
[00:46] <cehoyos> Don't worry, the samples are progressive.
[00:46] <ubitux> ok :)
[00:46] <cehoyos> (I wonder if decimate doesn't help for them, but I am not sure what he wants.)
[00:46] <cehoyos> What do you think about my pgi patches? Aren't they great?
[00:46] <ubitux> i'll wait for a proper bug report if any then
[00:47] <ubitux> pgi?
[00:47] <cehoyos> (It took me several hours to find out the problems and I still don't know how to disable optimizations for functions)
[00:47] <ubitux> ah the compiler thing
[00:47] <ubitux> ?
[00:47] <cehoyos> Portland Compilers, Inc or something like that
[00:47] <ubitux> :)
[00:48] <cehoyos> I really wonder now who is buying this compiler...
[00:48] <cehoyos> "entries++;" isn't exactly a special-case, is it?
[00:49] Action: ubitux needs more context
[00:49] <cehoyos> movenc.c contains a line "entries++;" which is compiled by pgcc so that valgrind exits and gdb reports a crash.
[00:49] <ubitux> lol
[00:49] <cehoyos> Workaround on mainling list.
[00:50] <cehoyos> I *think* we should not spend money for a license.
[00:50] <durandal_1707> cehoyos: pullup works, it just does not set pts ....
[00:50] <cehoyos> But if we get one, you will be the first to know
[00:51] <cehoyos> durandal_1707: Didn't I tell you? (I at least explained on trac.) That means it cannot be used on real content.
[00:51] <ubitux> omg
[00:51] <ubitux> cehoyos: seriously? :D
[00:52] <cehoyos> Seriously that you will be the first to know when we get a license? Yes!
[00:52] <durandal_1707> cehoyos: we should ban buggy compilers, gcc is first one
[00:52] <ubitux> cehoyos: i guess you tried += 1, pre-increment, ...?
[00:52] <cehoyos> I tried entries = entries + 1;
[00:52] <cehoyos> I did not try pre-increment!
[00:53] <ubitux> try to rename too
[00:53] <durandal_1707> to colour?
[00:53] <ubitux> :DD
[00:53] <cehoyos> durandal_1707: I asked here and on the mailing list if we should drop the compiler, on both places nobody wanted to drop it.
[00:53] <ubitux> what about reporting them bugs
[00:53] <ubitux> ?
[00:54] <cehoyos> (I had no strong opinion, but since I "fixed" - found - all problems, I would be a littel disappointed if we decide to drop it now.)
[00:54] <durandal_1707> i just do not want such kind of hacks in code (i can tolerate av_log() only)
[00:54] <ubitux> "please give us a license so we can show the world how bad your compiler is"
[00:54] <cehoyos> Sure, as soon as we have two licenses.
[00:55] <cehoyos> (I reported a large amount of bugs to Intel, all-in-all this was quite fruitless, iiuc, they do not accept reports anymore)
[00:58] <ubitux> "The Portland Garden Club"
[01:00] <durandal_1707> ubitux: you could also remove some silly comments (failed jokes) in gif encoder
[01:00] <ubitux> feel free to remove them if you understand
[01:00] <michaelni> ubitux, did you break gif 
[01:00] <ubitux> michaelni: huh?
[01:00] <michaelni> fate-lavf-gif
[01:00] <ubitux> i checked it before pushing
[01:01] <michaelni> Assertion b>=-128 && b<=255 failed at libavformat/aviobuf.c:153
[01:01] <michaelni> maybe this needs --assert-level=2
[01:02] <ubitux> mmh
[01:02] <ubitux> i'll check
[01:02] <cehoyos> michaelni: I would like to commit the s/O1/O patch (it is just a bug in configure), could you comment on entries++ ?
[01:02] <durandal_1707> entries2 is hack
[01:03] <durandal_1707> its ugly
[01:03] <cehoyos> I will test pre-increment before pushing anthing
[01:04] <michaelni> cehoyos, is there some manual that explains what the -O options mean for pgc ? and maybe also other options?
[01:05] <cehoyos> -O means "Sets the optimization level to 2, with no SIMD vectorization enabled.  All level 1 optimizations are performed. In addition, traditional scalar optimizations such as induction recognition and loop invariant motion are performed by the global optimizer."
[01:05] <ubitux> michaelni: do you know which one triggers this?
[01:05] <cehoyos> -O1 disables dead code elimination and therefore cannot be used for FFmpeg compilation.
[01:06] <cehoyos> (I did not find an option for dead code elimination)
[01:06] <cehoyos> What does "induction" mean?
[01:06] <michaelni> ubitux, fate-lavf-gif
[01:06] <durandal_1707> ubitux: you removed gif from img2 but there is still test for it
[01:07] <ubitux> wait, how is that possible?
[01:07] <ubitux> i mean i've run fate several times..
[01:07] <durandal_1707> it fails here too
[01:07] <ubitux> --assert-level indeed helps.
[01:08] <durandal_1707> you did not applied some chunk?
[01:08] <ubitux> ?
[01:09] <ubitux> it seems to choke on libavformat/gif.c:52 for some reason
[01:10] <ubitux> reverting dfb32310 fixes it
[01:10] <ubitux> but i don't understand..
[01:11] <durandal_1707> ubitux: overreads pallete?
[01:11] <michaelni> ubitux, what is v there ?
[01:11] <michaelni> maybe its too large to fit in 24bit
[01:11] <ubitux> michaelni: possibly a value with alpha channel
[01:12] <ubitux> ok
[01:12] <ubitux> v & 0xffffff would help then i guess
[01:15] <cone-483> ffmpeg.git 03Clément BSsch 07master:b6408ffc4534: lavf/gif: fix assert in avio API after dfb3231.
[01:17] <durandal_1707> hmm that is little clumsy, shouldn't av_wb24 ignore other 8 bits?
[01:17] <durandal_1707> and fate still fails here
[01:18] <michaelni> here too :(
[01:18] <ubitux> how does it fail?
[01:18] <durandal_1707> i get -/+ lines
[01:18] <ubitux> durandal_1707: which test?
[01:18] <michaelni> i get lots of -
[01:18] <michaelni> fate-lavf-gif
[01:18] <durandal_1707> ^
[01:19] <michaelni> if that works for you maybe you need a distclean, but its a wild guess
[01:19] <ubitux> yeah i'll try a violent git clean
[01:19] <durandal_1707> "git status" spams screen?
[01:20] <ubitux> non my git status is empty
[01:20] <michaelni> the first line with a - fir me is: -022dc66b5068404e88c618ce79d9eb5f *./tests/data/images/gif/02.gif
[01:20] <durandal_1707> ubitux: noooo, you will erase all that animes ..
[01:20] <ubitux> i've just moved my 2 samples in the local dir :)
[01:20] <cehoyos> michaelni: The pgcc O levels are also explained on page 9 of http://www.pgroup.com/doc/pgirn133.pdf
[01:21] <michaelni> ubitux, cleaning test directory should be enough i suspect
[01:21] <michaelni> testS
[01:23] <ubitux> oh now indeed it fails
[01:24] <michaelni> cehoyos, thanks
[01:26] <durandal_1707> cehoyos: if pullup works for that user maybe because it can recognize progressive frames
[01:29] <ubitux> can i disable the gif tests for now and rewrite some proper tests?
[01:32] <durandal_1707> ubitux: test of what?
[01:33] <durandal_1707> just disable irrelevant ones, they still check for IMAGE2
[01:35] <durandal_1707> and just update ref?
[01:35] <ubitux> i'll commit a quick fix
[01:35] <michaelni> -rw-r----- 1 michael michael 1047862 Apr 18 01:33 %02d.gif
[01:36] <ubitux> yes i get the problem
[01:37] <durandal_1707> cehoyos: instead of working on pgc, why not increase our fate coverage?
[01:44] <cone-483> ffmpeg.git 03Clément BSsch 07master:32cc7ba8a70a: fate: hot fix for gif failure.
[01:44] Action: ubitux working on relevant fate tests
[01:57] <cone-483> ffmpeg.git 03Michael Niedermayer 07master:bdfe60c769f4: xan: Check for overlapping copies
[02:18] <cehoyos> durandal_1707: Allow me to repeat: I asked yesterday both here and on the mainling list if we should drop pgc support, and nobody wanted to drop it. Apart from that I hope you agree that "free" in "free software" also means that we are free to work on whatever we want.
[02:19] <ubitux> cehoyos: supporting it is fine as long as it doesn't need any crazy hacks like the last one :p
[02:21] <megaTherion> mhm anyone has a good example how to read frame's of an mpeg4 video? I tried already avformat_open_input (which works) and then av_read_frame but I still cant get it right.
[02:21] <cehoyos> michaelni: Patch applied, please merge
[02:22] <cehoyos> ubitux: I don't consider a workaround in a piece of code that is called once per output file "crazy". (I find it crazy that we support a broken compiler but have no arm64 fate box.)
[02:22] <michaelni> ubitux, cehoyos about pgc, its possible that theres code with undefined behavior and that the change that "fixes" it is just random and unrelated
[02:24] <michaelni> one would have to try to reduce it to a minimal testcase to know what is needed for it to fail
[02:24] <ubitux> cehoyos: problem is, in 6 months/1yr, someone will see this weird workaround and will likely have no way of testing if it's still relevant (or if it still works)
[02:24] <cehoyos> I don't understand.
[02:24] <durandal_1707> hmm, what about #ifdef FF_BORKEN_COMPILER_HACK
[02:25] <ubitux> cehoyos: "hey this code can be simplified... wait changing this code might break a build with a compiler. wtf is this change, how can i know if a change in the code around won't break it again? is that intermediate variable really fixing anything? is it still true noawadays?"
[02:25] <ubitux> when the scope of the hack is not defined, that's wrong
[02:26] <ubitux> in the case of color/colour it's ok because we know the exact reason of the clash
[02:26] <ubitux> in your last patch, we don't
[02:26] <ubitux> that's complete random guess that seems to work for some unknown reason
[02:26] <cehoyos> Apart from fate which reports within 24h if it still works, it can be tested anytime, where is the problem?
[02:27] <durandal_1707> make your time more useful
[02:27] <ubitux> scare people away
[02:27] <ubitux> "can i really submit a patch changing this code?"
[02:27] <ubitux> "it might break"
[02:27] <durandal_1707> who is going to compile ffmpeg with pgc?
[02:28] <cehoyos> durandal_1707: Next time when I ask if I should work on something, please don't tell me afterwards you would have preferred that I don't!
[02:28] <ubitux> cehoyos: this patch is definitely intrusive for a very evasive reason :) that's the main problem
[02:28] <ubitux> and we don't understand the problem
[02:28] <cehoyos> ubitux: Test it, what would you do with an icc or gcc workarounds (don't tell me they don't exist) - or msvc
[02:29] <ubitux> afaik we have some explanations for the failures
[02:29] <ubitux> and the workarounds aren't that intrusive
[02:29] <ubitux> and finally... pgc.
[02:29] <durandal_1707> cehoyos: your are mixing stuff....
[02:29] <michaelni> IMHO someone should try to build a minimal testcase
[02:30] <michaelni> and that either will then point to a bug in our code or the compiler
[02:30] <michaelni> if ours, we should fix, if the compiler we should report
[02:30] <cehoyos> Look, you don't have to explain that to me: I wanted to drop support, since that wasn't accepted. I found all (!) issues. Please neither teach me what I should work on (especially if you didn't tell me in advance) nor fight hacks that are clearly marked as such.
[02:30] <ubitux> btw, if a compiler is choking on a "entries++" i wonder how the rest of the code can actually work...
[02:31] <cehoyos> ubitux: Could you answer on ffmpeg-user?
[02:31] <ubitux> cehoyos: what thread?
[02:31] <durandal_1707> cehoyos: i don't teach you, neither i fight
[02:31] <cehoyos> The latest
[02:31] <cehoyos> You do
[02:32] <ubitux> average audio level?
[02:32] <cehoyos> In the most offensive way possible.
[02:35] <cehoyos> ramitbhalla is trying to beat my two favorite trac users, how impressive!
[02:36] <cehoyos> s/two/two most
[02:36] <ubitux> ?
[02:36] <ubitux> good reports?
[02:36] <cehoyos> He made me download a 3G sample for three hours and it contains junk
[02:36] <durandal_1707> cehoyos: if you really want very offensive attack, i can start with trac tickets....
[02:36] <ubitux> cehoyos: is that an anime at least?
[02:37] <cehoyos> Since it is junk, it is hard to say, but I suspect it is a recording from television (I actually know)
[02:37] <ubitux> :)
[02:44] <cehoyos> durandal_1707: Did you ever look at the hikvision samples? I would be very surprised if they aren't just xor'ed h264
[02:45] <durandal_1707> cehoyos: related to above mentioned bug?
[02:45] <cehoyos> No.
[02:46] <ubitux> hikvision samples? you mean the chinese guys with a fake mp4 from a security camera?
[02:47] <cehoyos> Do you think it is a mp4 ?
[02:47] Action: durandal_1707 needs more background info
[02:47] <ubitux> the file was .mp4 iirc but that wasn't mp4
[02:47] <durandal_1707> and sample
[02:47] <cehoyos> We don't have more;-(
[02:47] <cehoyos> http://samples.ffmpeg.org/camera-dvr/hikvision/
[02:48] <cehoyos> (One of them plays fine, it is a different type)
[02:48] <cehoyos> The DVR_NVR iirc
[02:51] <durandal_1707> because it starts with IMKH
[02:51] <durandal_1707> its detected as some format or just parsers are lucky
[02:51] <durandal_1707> ?
[02:52] <cehoyos> What file are you looking at?
[02:52] <durandal_1707> the one that plays fine
[02:52] <durandal_1707> IMKH i presume
[02:52] <durandal_1707> DVR_...
[02:53] <cehoyos> Sorry for being unclear: This is the only file that you don't have to look at (you may if you want, but the file plays fine afaict so there will not be much to fix), all other files - iirc - are relevant because they cannot be played.
[02:54] <durandal_1707> yes, but its mp4 or what?
[02:54] <cehoyos> Isn't it mpg?
[02:54] <cehoyos> a program stream I mean
[02:54] <cehoyos> ?
[02:54] <cehoyos> Or do you mean the other files? We don't know, afaict nobody knows
[02:55] <durandal_1707> googling for 4HKH reveals mplayer entries from 2009
[02:55] <durandal_1707> its some cctv crap
[02:56] <cehoyos> I would be very surprised if any of the entries you find can tell you anything important (I suspect I wrote 50% of them)
[02:57] <durandal_1707> it could be just container thing, which should not be hard to reverse, if its codec also - its more complicated...
[02:58] <cehoyos> I think we can rule out a codec (they say on the homepage that it is h264), and I don't think they invented a container, I assume they are using a very simple "encryption" like xor
[02:59] <cone-483> ffmpeg.git 03Michael Niedermayer 07master:fb3e3808aed8: avcodec/bitstream: Check bits in ff_init_vlc_sparse()
[02:59] <cone-483> ffmpeg.git 03Michael Niedermayer 07master:6998af4a40e6: avcodec/bitstream: check codes in ff_init_vlc_sparse()
[02:59] <durandal_1707> it plays when right drivers are installed?
[03:00] <cehoyos> The txt file says so and if you search irc for the discussion we had when I fixed the DVR sample, I believe they pointed me to an installer that plays the 4HKH files
[03:00] <cehoyos> (iirc)
[03:00] <durandal_1707> find relevant drivers and then open it in dissasembler and start reading....
[03:03] <durandal_1707> lol, gif muxer in header frees its own private context
[03:05] <durandal_1707> ubitux: what that last line means: "separatefields,joinfields is a no-op, even for timestamps?"
[03:05] <ubitux> if the frames are the same before and after
[03:05] <ubitux> including their pts
[03:05] <durandal_1707> Compn already send me sample and drivers of some game long ago, didn't do any serious work on it....
[03:06] <durandal_1707> ubitux: it plays fine, and everythings looks fine too, but i wonder could same be done without frame_count hack....
[03:08] <cone-483> ffmpeg.git 03Carl Eugen Hoyos 07master:2ade23a7ada6: Fix pgc compilation with --disable-optimizations.
[03:08] <cone-483> ffmpeg.git 03Michael Niedermayer 07master:ee94362c8a6a: Merge remote-tracking branch 'cehoyos/master'
[03:12] <ubitux> durandal_1707: the frame_count hack will go away soon
[03:13] <ubitux> at least simplified in a first step
[03:13] <ubitux> but i need a OK for the timeline patchset
[03:15] <durandal_1707> the enable thing iirc, nicolas does not like it
[03:15] <ubitux> yes, but i do, and stefano seems to be interested in as well
[03:15] <ubitux> what's your opinion?
[03:16] <ubitux> nicolas didn't reply to my last mail btw
[03:18] <durandal_1707> its interesting (global options), but i want more poverful solution... like conditional filtering or actual scripting filter that is smart and creates filtergraph when needed....
[03:18] <durandal_1707> i dont see how that enable thing can hurt that much...
[03:20] <durandal_1707> so you could talk with nicolas what is (his) prefered way to do it
[03:22] <durandal_1707> highgod: Snaggle is looking for you
[03:24] <cehoyos> ubitux: The user is happy;-))
[03:24] <cehoyos> Good night!
[03:26] <ubitux> it's ok to create a new side data in the encoder, and get it from the muxer, right?
[03:26] <durandal_1707> for what?
[03:27] <ubitux> palette
[03:28] <ubitux> that gif stuff is still quite messy :)
[03:28] <durandal_1707> and why would muxer need it?
[03:29] <ubitux> because it is needed to flag the data
[03:29] <durandal_1707> so you sent just single byte?
[03:30] <durandal_1707> it should possible...
[03:30] <ubitux> no i'd prefer to send the complete palette
[03:30] <ubitux> there is a type for it
[03:30] <ubitux> it works somehow fine but i get invalid free for some reason
[03:31] <durandal_1707> where its allocated?
[03:31] <ubitux> encoder: av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE, AVPALETTE_SIZE);
[03:31] <ubitux> muxer: palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
[03:32] <ubitux> but then i get that kind of stuff: http://pastie.org/7638659
[03:32] <ubitux> of course it's possible i'm messing somewhere else
[03:36] <ubitux> http://b.pkh.me/0001-gif-use-only-one-graphic-control-extension-block-per.patch
[03:36] <ubitux> i don't really get why it fails..
[03:39] <durandal_1707> shrink_side_data?
[03:41] <ubitux> idk :(
[03:41] <durandal_1707> only libavcodec/mpegvideo_enc.c is doing something similar, so wake up michaelni 
[03:42] <durandal_1707> i'm doing some cleanups with gif muxer/encoder like using gif.h
[03:43] <ubitux> erm
[03:43] <ubitux> well ok
[03:43] <ubitux> i actually did that already but dropped it from my current tree for a random reason
[03:43] <durandal_1707> aw, why?
[03:43] <ubitux> please let me fix the palette and timestamping problem though :)
[03:44] <ubitux> durandal_1707: because it was in the middle of other changes and not easy to fix
[03:44] <ubitux> also
[03:44] <ubitux> see the code i'm moving..
[03:44] <durandal_1707> yes, i know you do not like conflicts.....
[03:44] <durandal_1707> i can leave it to you after all ...
[03:44] <ubitux> thx :)
[03:44] <ubitux> i should be done with gif in a few days
[03:46] <durandal_1707> no rush (looks for how many years it was in this state...)
[03:46] <ubitux> i have tons of other crazy/fun projects
[03:46] <ubitux> so i want to get done soon :)
[03:47] <durandal_1707> also remove that PDP_ENDIAN comment nonsense while you are at it
[03:48] Action: durandal_1707 hopes noone comes with patch to support that ....
[03:50] <ubitux> feel free to remove it right away
[03:50] <ubitux> it won't conflict with my work
[03:51] <ubitux> 7 entries in my gif todo list, fear.
[03:52] <durandal_1707> link?
[03:53] <ubitux> top secret
[03:53] <ubitux> and written on a white board so..
[11:54] <durandal_1707> saste: i did not get new comments on colorbalance so i will likely apply
[11:56] <saste> durandal_1707, i'll do another quick review in an hour
[11:56] <saste> as for the syntax thing i'd like to hear a third opinion
[11:58] <ubitux> syntax?
[11:58] <ubitux> you mean the range?
[11:58] <ubitux> mmh we need to review some user patches...
[11:59] <ubitux> fade, smv, ..
[11:59] <durandal_1707> saste: i changed 200 to 2 for colorchannelmixer as I have better time to do then waste time
[12:00] <saste> durandal_1707, thanks
[12:06] <saste> ubitux, smv?
[12:06] <ubitux> [FFmpeg-devel] [PATCH 2/2] Support playing SMV files.
[12:06] <ubitux> i can't really review it though
[12:07] <durandal_1707> because?
[12:08] <ubitux> not my area :)
[12:09] <saste> ^^ random excuse #12
[12:10] <ubitux> :D
[12:17] <durandal_1707> also added 16bit support to mixer
[12:48] <cone-523> ffmpeg.git 03Carl Eugen Hoyos 07master:99818ac4d371: Fix libswscale compilation with --disable-optimizations on x86-32.
[13:08] <cone-523> ffmpeg.git 03Michael Niedermayer 07master:978e373499e2: cmdutils: make the "-help filter=" output less confusing
[13:45] <cone-523> ffmpeg.git 03Clément BSsch 07master:28f9858c91ff: lavf/gif: simplify streams type checking.
[13:45] <cone-523> ffmpeg.git 03Clément BSsch 07master:0a0e6877ff3b: lavf/gif: remove unused fields.
[13:45] <cone-523> ffmpeg.git 03Clément BSsch 07master:b7a3f143604c: lavf/gif: trim unnecessarily long netscape ext code.
[13:45] <cone-523> ffmpeg.git 03Clément BSsch 07master:01367b0fca0c: lavf/gif: merge gif_write_{packet,video}.
[13:47] <durandal_1707> ubitux: i wanted to check for GIF codec not for unsect codec ....
[13:47] <durandal_1707> you dont want to put h264 into gif, do you?
[13:47] <durandal_1707> i thought it was abvious, but then ....
[13:49] <ubitux> oh, sorry, misunderstood
[13:49] <ubitux> will fix
[13:54] <cone-523> ffmpeg.git 03Clément BSsch 07master:9db1c6455e47: lavf/gif: support only GIF codec.
[14:05] <ubitux> ts fixed, yay.
[14:07] <durandal_1707> ubitux: ?
[14:10] <ubitux> actually, almost
[14:10] <ubitux> the timestamps are incorrect with the gif muxer
[14:26] <ubitux> avpriv_set_pts_info(s->streams[0], 64, 1, 1000) ’ pkt->duration=1000
[14:26] <ubitux> avpriv_set_pts_info(s->streams[0], 64, 1, 100)  ’ pkt->duration=1
[14:26] <ubitux> wut?
[14:26] <ubitux> isn't duration supposed to be 100 in the second case?
[14:32] <ubitux> the durations looks all broken for some reason when i set 1/100 in the encoder
[14:32] <durandal_1707> what you use as source?
[14:33] <ubitux> lavfi testsrc and a play with the rate parameter
[14:33] <ubitux> i tried r=1, r=10, r=30, r=100...
[14:33] <ubitux> and i always get pkt->duration=1 with set pts info 1/100
[14:34] <ubitux> with 1/1000 i get more meaningful duration
[14:34] <durandal_1707> so created gifs play too slow?
[14:35] <ubitux> well, basically delay calculation is broken if i use the pkt->duration
[14:35] <ubitux> it's easy to fix, i just need to set pts info to 1/1000
[14:35] <ubitux> and rescale myself
[14:35] <ubitux> but i wanted to let the internal rescale correctly by themselves
[14:35] <ubitux> by just setting 1/100
[14:50] <durandal_1707> ubitux: you resolved that side data issue?
[14:51] <ubitux> no
[14:51] <ubitux> :(
[14:51] <durandal_1707> ubitux: pinged michaelni?
[14:51] Action: ubitux ping michaelni
[15:00] <durandal_1707> michaelni: why is there no av_clipd ?
[15:01] <ubitux> because it's called av_clip()?
[15:01] <durandal_1707> av_clip is interger only
[15:01] <ubitux> what would clipd be then?
[15:01] <ubitux> double?
[15:01] <durandal_1707> similar to av_clipf
[15:04] <durandal_1707> to make audio users happy
[15:07] <durandal_1707> ubitux: so writing filters is more fun than encoders?
[15:08] <ubitux> not really
[15:09] <ubitux> i'm just not comfortable with them yet :p
[15:14] <durandal_1707> so i'm adding av_clipd and pushing two new filters
[15:15] <ubitux> don't change the api without sending a patch..
[15:15] <durandal_1707> i just add new function in header ......
[15:25] <michaelni> durandal_1707, if a av_clipd() is needed, we should add one
[15:26] <durandal_1707> my filter needs it
[15:32] <cone-523> ffmpeg.git 03Clément BSsch 07master:90a56ebbe586: lavc/gif: avoid encoding 0x0 images.
[15:47] <durandal_1707> sent av_clipd patch
[15:49] <ubitux> michaelni: any idea how i could make the dithering smoother: http://lucy.pkh.me/nut.gif ?
[15:50] <michaelni> ubitux, choose a better palette, also error diffusion might help a bit
[15:51] <ubitux> problem with error diffusion is that it randomize too much between frames
[15:51] <michaelni> i know
[15:51] <michaelni> cluster and void dither might help a tiny bit too
[15:52] <michaelni> or some rotated bayer dither
[15:52] <ubitux> ok :p
[15:52] <michaelni> or maybe you can find a way to reduce the temporal change with ER
[15:53] <michaelni> ED i meant ;)
[15:53] <nevcairiel> could try a randomized dithering pattern instead of the ordered dithering pattern
[15:54] <durandal_1707> ubitux: i thought you where working on pal8
[15:55] <ubitux> problem with using pal8 is that it will generate a palette per frame
[15:55] <durandal_1707> dithering with bad pallete cant make results much better ...
[15:55] <ubitux> so using pal8 makes sense if it's a static gif
[15:55] <ubitux> for animated, that's not a good idea
[15:56] <durandal_1707> ubitux: yes, but you could still generate palette in encoder only ... (ignore pal8 for now)
[15:56] <ubitux> i don't understand what you want me to do
[15:56] <michaelni> 2pass palette generation
[15:57] <michaelni> first pass find optimal palette for whole video
[15:57] <durandal_1707> ubitux: did you looked at all those fancy gif samples....
[15:57] <ubitux> durandal_1707: not yet :p
[15:58] <durandal_1707> michaelni: exactly, 2 pass gif encoder
[16:00] <ubitux> yeah, maybe later :)
[16:02] <durandal_1707> i want that av_clip to be applied asap, as i want to push nice filters
[16:15] <michaelni> durandal_1707, approved but you can just work on top of such a commit ignoring if its in master or not
[16:20] <durandal_1707> michaelni: its part of colorbalance...
[16:29] <cone-523> ffmpeg.git 03Michael Niedermayer 07master:5ae484e350e4: evrcdec: use memmove() instead of memcpy() when regions can overlap.
[16:40] <durandal_1707> awww
[16:48] <ubitux> michaelni: any idea why using av_packet_new_side_data() in an encoder breaks?
[16:48] <ubitux> so far, there is only one case: libavcodec/mpegvideo_enc.c:            s->mb_info_ptr = av_packet_new_side_data(pkt,
[16:48] <ubitux> i'm not sure if it works
[16:48] <ubitux> but if i do that in the gif encoder, i get http://pastie.org/7644834
[16:49] <ubitux> (http://b.pkh.me/0001-gif-use-only-one-graphic-control-extension-block-per.patch)
[16:49] <ubitux> (the lavf part can be ignored, using only the lavc chunk is enough to trigger the invalid read)
[16:55] <michaelni> ubitux, you wrote that split_write_packet() stuff for the muxer side
[16:55] <michaelni> so you should know why it or surrounding code doesnt work :)
[16:57] <ubitux> mmh
[16:58] <ubitux> it's the encoder part here :(
[16:59] <michaelni> it works with demxuer->muxer and not encoder->muxer ?
[16:59] <michaelni> if so whats the difference?
[17:03] <ubitux> maybe side data are not merged after the encoder
[17:16] <durandal_1707> :-) Classification: UNCLASSIFIED   Caveats: NONE
[17:20] <ubitux> it seems that merging side data after the encode solve my problem
[17:20] <ubitux> though, i'm actually wondering if adding side data to the packet in the encoder is ok
[17:21] <ubitux> oh well, yeah derp it's fine
[17:37] <cone-523> ffmpeg.git 03Paul B Mahol 07master:3e9c0217fdd3: lavu: add av_clipd_c
[17:37] <cone-523> ffmpeg.git 03Paul B Mahol 07master:449cdd547b30: colorbalance filter
[17:37] <cone-523> ffmpeg.git 03Paul B Mahol 07master:212960eea4c0: colorchannelmixer filter
[17:38] <ubitux> erk, dup :)
[17:39] <ubitux> durandal_1707: fate! :(
[17:46] <durandal_1707> doubles are used, so i'm afraid it could make fate yellow
[17:49] <ubitux> btw, anyone has any objection with the vf xyz convert?
[17:49] <ubitux> it seems libav is delaying it for months
[17:49] <ubitux> and at least one person want it
[17:49] <durandal_1707> it shuld not be rocket science to incorporate it in colormatrix
[17:51] <ubitux> btw, it seems people want 3d lut in ffmpeg
[18:05] <cone-523> ffmpeg.git 03Michael Niedermayer 07master:4c8ce750abaa: svq3: use memmove to avoid overlap in memcpy.
[18:23] <Compn> ubitux : we should apply it until someone puts it in swscale or whatever 
[18:23] <Compn> theres no reason to sit on it
[18:23] <Compn> that kind of '47-reviews' of a patch and 'lets not implement anything until we do it right' type development has been hampering things and splitting up developers into other projects
[18:24] <Compn> making people fork (ffmbc, etc) and reinvent wheels
[18:24] <Compn> for little reason (its a hack, its not correct api, etc)
[18:25] <Compn> at least imo. i cant speak for everyone :)
[18:28] <ubitux> ok i'll work on it then
[18:28] <ubitux> ... when i'm done with this !@# gif
[18:48] <durandal_1707> http://www.hydrogenaudio.org/forums/index.php?showtopic=100448&hl=
[19:06] <ubitux> michaelni: no idea for the timing problem?
[19:06] <ubitux> ([PATCH/WIP] lavf/gif: fix timing.)
[19:11] <seanDuncan> I'm wondering if someone can tell me what specific container atom ffmpeg looks to when it is determining the pixel format of a pro-res encoded file inside of a .mov container (IE where it gets the information to know that the file's pixel format is (for example) 'yuv422p10le' from)
[19:12] <michaelni> ubitux, are you setting dts/pts ?
[19:13] <ubitux> michaelni: i tried with different sources
[19:14] <ubitux> my test case being mainly -f lavfi -i testsrc=r=XXX
[19:14] <ubitux> michaelni: the question is why the pkt->duration is (completely) fucked up when the precision is 1/100 but ok with 1/1000
[19:15] <ubitux> (on muxer side)
[19:15] <michaelni> dunno but you should possibly set AVFMT_VARIABLE_FPS
[19:15] <ubitux> mmh
[19:16] <michaelni> if that doesnt help it could also be a bug outside gif*c
[19:18] <ubitux> doesn't help
[19:18] <ubitux> still get pkt->duration=1 whatever the rate
[19:18] <seanDuncan> I'm wondering because I'm finding that some of my proRes .mov files require me to add '-analyze_duration' and '-probesize' to get the pixel format to be properly detected.  I'm hoping that by finding the location I can detect automatically, beforehand (via my own application), when to increase ffmpeg's analyze duration and probe size.  
[19:19] <ubitux> michaelni: it's reproducible with any den < 1000
[19:20] <michaelni> and works with >= 1000 ?
[19:20] <ubitux> yes
[19:21] <ubitux> seanDuncan: it's likely looking into various trak sub atoms
[19:21] <ubitux> seanDuncan: having the moov header on top helps?
[19:21] <ubitux> michaelni: do you want a branch to reproduce?
[19:23] <ubitux> michaelni: github/ubitux/gif-muxing ; then: ./ffmpeg -f lavfi -i testsrc=r=30 -y testsrc.gif
[19:23] <ubitux> pkt->duration is logged; if you try to change the 1000 into something < it goes to 1 immediately
[19:27] <seanDuncan> Unfortunately, having the moov header at the top doesn't help.  I still run into times where I have to increase analyzeduration and probesize even when moov is at the top
[19:28] <seanDuncan> I have looked at the box structure via Apple's 'Atom Inspector' tool, however I can't find the exact byte range where it says 'yuv422p10le.'  My guess is that there is some byte range in the the track holding the video that must have some sort of code that maps to 'yuv422p10le' but I just don't know where to look for that code.   
[19:32] <ubitux> possibly in one of the the stsd leaf tables of the trak
[19:32] <ubitux> add some debug in lavf/mov.c
[19:33] <michaelni> ubitux, iam not sure your use of duration in the muxer is a good idea
[19:34] <michaelni> currently its set from ff_compute_frame_duration()
[19:34] <ubitux> should i do some pts diff instead?
[19:34] <michaelni> so its not the actual durations just values based on frame rate
[19:35] <michaelni> i think thats better if it can be done
[19:35] <ubitux> yeah sure it should be possible
[19:36] <seanDuncan> @ubitux: thanks, can you suggest a couple of places that would be good for me to add debug printouts in mov.c? 
[19:36] <ubitux> seanDuncan: read header, stsd, anything function setting codec_id or similar video codec settings
[19:40] <seanDuncan> @ubitux: ok, I'll start there. thanks.
[19:42] <ubitux> michaelni: seems to work fine, thank you :)
[19:43] <ubitux> finally good timing in gif files...
[19:47] <seanDuncan>  
[20:15] <cone-523> ffmpeg.git 03Michael Niedermayer 07master:23daee0dcc57: avcodec/mpegvideo_motion: Check P field references
[20:36] <cone-523> ffmpeg.git 03Nicolas George 07master:300ca0763b6d: examples/filtering_audio: fix frame leak.
[20:36] <cone-523> ffmpeg.git 03Michael Niedermayer 07master:5b9675b5ac89: Merge remote-tracking branch 'cigaes/master'
[21:49] <saste> durandal_1707, sepia effect?
[22:31] <Compn> cehoyos : what ticket is the one with the hikvision ? cant find it using search or googles :\
[22:31] <durandal_1707> its in roundup, dead now
[22:32] <Compn> i remember it in roundup
[22:32] <Compn> thought it got migrated
[22:43] <durandal_1707> iirc bug did not got migrated
[22:46] <ubitux> saste: what's your general opinion about the enable thing?
[22:46] <ubitux> saste: are you ok with it, or you would prefer the system nicolas is talking about?
[22:50] <saste> ubitux, i already commented on the patches and look fine to me
[22:51] <ubitux> ok, should i push then?
[22:51] <saste> i still have to read carefully the comments from nicolas
[22:51] <ubitux> oh i have to push the ass/ssa mmh
[22:51] <saste> ubitux, can you post updated patches?
[22:53] <ubitux> mmh i'm in the middle of a large change now, i'll do it asap
[22:57] <saste> how should I set the framerate in interleave?
[23:17] <durandal_1707> saste: same as input(s)?
[23:19] <saste> durandal_1707, 1/0
[23:20] <durandal_1707> ?
[23:23] <durandal_1707> also, thare are new flags for dynamic inputs/outputs ....
[23:24] <saste> uhm yes
[23:29] <saste> who's going to attend the gsoc feedback session tomorrow?
[23:30] <saste> it will be 16:00 UTC (18:00 CEST)
[23:30] <saste> michaelni, ubitux?
[23:30] <ubitux> saste: i'll be there
[23:30] <cone-523> ffmpeg.git 03Clément BSsch 07master:7c1a002c78f1: subtitles: introduce ASS codec id and use it.
[23:30] <saste> llogan already said he won't be present (I should)
[23:31] <saste> ok, i'll announce the event on this channel one hour before the beginning
[23:33] <michaelni> ill be present unless my net connection is down or something else unexpected
[23:34] <saste> allright, thank you
[23:34] <ubitux> wow, that ass/ssa thing is a relief.
[23:34] <ubitux> what a pain
[23:49] <cone-523> ffmpeg.git 03Stefano Sabatini 07master:c6a43a72444a: lavfi/mptestsrc: fix invalid access in case of negative linesize
[23:49] <cone-523> ffmpeg.git 03Michael Niedermayer 07master:020c287f5ee5: avformat: Dont stop probing before the whole id3 tag is read
[23:59] <ubitux> saste: mmh, i wasn't able to get the option thing working
[00:00] --- Fri Apr 19 2013