[01:25] <cone-898> ffmpeg.git 03Michael Niedermayer 07master:c25d2cd20b76: avcodec/x86/mpegvideoenc_template: fix integer overflow [03:46] <cone-898> ffmpeg.git 03Michael Niedermayer 07master:a81ee2651faf: avcodec/svq1enc: fix undefined pointer operation [10:31] <j-b> 'morning [10:33] <ubitux> BBB: i forgot to run the 20k encode for vp9 with the others at the beginning, so it's running since 2 days now and should be done tonight [10:33] <ubitux> you'll have full results soon, but here is a teaser: http://lucy.pkh.me/encodeshd/ssim-summary.txt [10:33] <ubitux> vs http://lucy.pkh.me/encodes/ssim-summary.txt [10:48] <ubitux> we need to do something about those :( [10:48] <JEEB> can anyone else test if they can replicate this? Going through `ffmpeg -i in.mp4 -vn -an -c:a aac -strict experimental out.mp4` multiple times seems to actually add the decoder delay into the encoded material without marking it correctly? [10:49] <JEEB> I re-encode a clip without seemingly any decoder delay (duration = 4561920 (00:01:35.040)) and get correct stuff (segment_duration = 95040). Then if I re-encode that, I get lolwut (segment_duration = 95061). [10:49] <pippin> ubitux: did you confirm that the gif encoder/muxer no longer does transparency diffing? [10:49] <JEEB> (values from tkhd and edit list checked by boxdumper) [10:50] <JEEB> 95061 being the tkhd duration of the first re-encode [10:51] <JEEB> tl;dr either I'm misparsing or ffmpeg cli is DoingItWrong [10:51] <ubitux> JEEB: -vn -an -c:a aac? huh? [10:51] <ubitux> pippin: how to reproduce? [10:51] <JEEB> ubitux, typoe [10:51] <JEEB> -sn [10:52] <JEEB> basically to make sure that it's only audio [10:52] <ubitux> wm4: not that simple, but feel free to do it [10:52] <wm4> ubitux: why not? [10:52] <ubitux> wm4: you probably want to change ff_subtitles_read_chunk() [10:52] <pippin> ubitux: bayer dithering and error diffusion ending up with roughly the same file size in a gif anim - that didn't happen in august when I was working on (other) dithering methods [10:53] <wm4> ubitux: the only hard part is not getting flamed and shitted on by nicolas [10:53] <ubitux> yeah nicolas had a complex WIP for that [10:53] <ubitux> but i havent heard any news since a while about that [10:53] <pippin> ubitux: the commandlines I used then, were of this form: $ ./ffmpeg -i bbb-original.mp4 -vf scale=320x180:sws_dither=bayer -r 10 -ss 40 -frames 100 bayer.gif [10:53] <ubitux> so please go ahead [10:54] <ubitux> pippin: did you try to revert to the commit you think cause problem, then drop it, and check if that was indeed the cause? [10:55] <pippin> opening up the gif anims in gimp, showed me that every frame in both versions are complete frames with no transparency [10:55] <ubitux> wm4: i support the utf16 "hack" in the chunk reader [10:56] <ubitux> wm4: but you need to change ff_get_line() and ff_subtitles_read_chunk() [10:56] <wm4> why is there both [10:56] <pippin> ubitux: I tried bisecting and building other versions; but at the moment I do not have sufficient battery/energy in my laptop to pursue further testing [10:56] <ubitux> wm4: because that's not the same thing [10:57] <ubitux> wm4: read_chunk() is "chunk" based (multi line read) [10:57] <ubitux> pippin: just try what i said [10:57] <ubitux> git checkout <the-hash-you-pointed-out> [10:57] <ubitux> do the test [10:58] <ubitux> git reset --hard HEAD^ [10:58] <ubitux> do the test again [11:00] <pippin> ubitux: I tried bisecting the problem, but came up empty handed - and at the moment I am unable to allocate my laptop battery to building ffmpeg [11:01] <ubitux> that's just one compilation [11:02] <pippin> the 1h40min of battery I have left, will be 10min left after that [11:03] <ubitux> pippin: note that transparency won't work with palette [11:04] <pippin> it used to work, and is the reason bayer / a_dither / x_dither are half the file size of error diffusion at http://pippin.gimp.org/a_dither/ [11:04] <ubitux> make sure it's not using pal8 [11:05] <ubitux> i could add a warning in case pal8 is used with gif encoder [11:06] <ubitux> it doesn't have any benefit [11:06] <pippin> why? [11:06] <ubitux> why why? [11:07] <pippin> if pal8 is 2 bit red, 4 bit green 2 bit blue; then it surely has benefit - as you can see on that page [11:07] <ubitux> pal8 can change palette, so it's not simple to handle properly [11:08] <ubitux> i think you're looking for rgb4 [11:08] <ubitux> or bgr4 [11:08] <ubitux> or simply, just use rgb8/bgr8 [11:09] <pippin> I think rgb8 is what ffmpeg-land calls what I refer to and use here [11:09] <ubitux> anyway, pal can not be used with transparency [11:09] <ubitux> or well, without larger heuristic [11:10] <ubitux> see the todo in lavc/gif.c [11:11] Action: pippin has no desire to dig himself much deeper into things; I provided patches half a year ago [11:12] <pippin> and when I updated the unapplied patches; there are unrelated regressions making the actual contribution pointess ;p [11:12] <ubitux> did you send them to ffmpeg-devel? were they forgotten? [11:12] <ubitux> if you want them not to break, make sure they go upstream [11:12] <ubitux> and add a test [11:12] <pippin> I nagged michaelni in here, and he reworked 2/3 of the patches but ignored the actual new dithering methods after my refactoring of making them fit in [11:13] <ubitux> pippin: where is the thread? [11:14] <pippin> my current re-iteration of it, was sent to ffmpeg-devel - and there has been no response on the list to it, but libav has contacted me off-list :] [11:14] <pippin> http://ffmpeg.org/pipermail/ffmpeg-devel/2014-March/155851.html [11:14] <ubitux> i saw that thread [11:14] <ubitux> i'm asking for the thread with the patches [11:15] <ubitux> where there maybe is review and requests to make it acceptable for upstream :p [11:15] <pippin> that was done ad-inifinitum in here in august [11:16] <ubitux> i wonder what you want then [11:16] <ubitux> irc is not a good way of keeping track of forgotten review [11:16] <ubitux> & patches [11:17] <pippin> which I guess is why I send it to the mailinglist instead after discovering the regressions? [11:18] <pippin> the actual features in there are pointless with the regression in the gif encoding [11:18] <ubitux> ah i see the patches are in the link.. you won't get review like that [11:18] <ubitux> can you workaround the regression with -pix_fmt rgb8 ? [11:19] <pippin> that is a slight rework of the 4th patch in a series; the start of the series were applied - which were the refactoring to make things able to deal with more dithering methods [11:25] <wm4> ubitux: looks I talked too early - there are somewhat deep dependencies on AVIOContext [11:26] <Compn> pippin : probably michaelni forgot about it. ping him :) [11:27] <Compn> michael is a busy guy, but also he doesnt want to miss patches [11:27] <ubitux> Compn: can't be applied, there is a regression he's trying to fix [11:28] <ubitux> i still don't know if it's because of the pix_fmt and if the suggested workaround works though [11:28] <Compn> ah [11:29] <pippin> ubitux: I am _not_ trying to fix the regression, I am trying to report the regression [11:30] <pippin> the patch with the new features is updates and is a gift that can be accepted or not [11:30] <pippin> s/updates/updated/ [11:32] <ubitux> pippin: i don't see the patch on the mailing list (just a link to follow with maybe not up-to-date patches, in a mail asking for information, not patch submit), for a regression not easily reproducible, which you don't seem to be able to bisect yourself [11:32] <ubitux> what do you expect from us? [11:34] <pippin> interest in the regression at least [11:35] <ubitux> well, i would if i could reproduce [11:36] <pippin> try to transcode a video to GIF and see if it treats all frames as I-frames fully encoded, or if it does transparency based delta encoding? [11:37] <pippin> or at least reply to the email, stating what is done wrong. if things should have been reported in a bug tracker, or if patches should be sent in a different way to the list [11:38] Action: pippin understands why such unresponded email yields off-list replies from the fork :] [11:38] <BBB> michaelni: do you remember why vp7 wasn't merged? I got that question from across the isle [11:39] <BBB> ubitux: yay! [11:39] <BBB> also, SLOW!!! (omg for real man) [11:39] <ubitux> :) [11:39] <ubitux> pippin: [11:39] <ubitux> -rw-r--r-- 1 ux ux 3.3M Mar 25 11:39 notrans.gif [11:39] <ubitux> -rw-r--r-- 1 ux ux 1.8M Mar 25 11:39 trans.gif [11:39] <ubitux> ./ffmpeg -ss 40 -i ~/samples/big_buck_bunny_1080p_h264.mov -vf scale=320:240 -r 10 -frames 100 -gifflags -transdiff -pix_fmt rgb8 -y notrans.gif [11:39] <ubitux> ./ffmpeg -ss 40 -i ~/samples/big_buck_bunny_1080p_h264.mov -vf scale=320:240 -r 10 -frames 100 -gifflags +transdiff -pix_fmt rgb8 -y trans.gif [11:39] <ubitux> works for me [11:40] <Compn> BBB : you have the last email in the vp7 thread, according to my email client [11:40] <BBB> Compn: and I said it was OK right? [11:40] <BBB> at least that's what I remember [11:40] <Compn> BBB : peter ross suggested splitting and copying the code into seperate decoders so as not to slow down vp8 by .25% [11:41] <Compn> > Sorry, lots of other stuff went around, I forgot. [11:41] <Compn> > Do you have specific ideas on what could cause the 0.25%? I am inclined to say that 0.25% is OK, given that it gives us a new decoder. I'm not happy to give up 0.25% all over the place but we sometimes do it (e.g. to add threading, or to support partition-threading in vp8, etc.) so it's not completely outrageous... [11:41] <Compn> BBB : ^^ thats your mail [11:41] <ubitux> pippin: your mail was too vague to get any answer [11:41] <BBB> hm... I still think it's OK to merge [11:41] <BBB> 0.25% isn't awful [11:41] <Compn> BBB : what about splitting the decoders up , having duplicated code ? [11:41] <pippin> ubitux: none of "-gifflags +transdiff -pix_fmt rgb8" was needed half a year ago, powering up generator and firing up a compile [11:42] <Compn> BBB : i'm not arguing, just curious [11:42] <ubitux> pippin: -gifflags +transdiff is not mandatory, it's the same without [11:42] <ubitux> pippin: -pix_fmt rgb8 might not have been mandatory because it was picking that pix format instead of pal8 for some reason [11:43] <ubitux> that is what i told you already [11:43] <Compn> BBB : i mean if you reply and say its OK , fine. but your last mail was confusing :) inclined not happy ?? :) [11:43] <BBB> Compn: nobody is happy when stuff is slower [11:43] <Compn> some people arent english majors [11:43] <BBB> but it's ok [11:43] <ubitux> pippin: now you didn't answer my simple question weither it was workarounding the problem or not [11:44] Action: wm4 is afraid that something slightly more advanced to support utf16 subs will be abused to add 8-bit codepage conversion support [11:44] <Compn> ok [11:44] <ubitux> pippin: if you can workaround the problem with -pix_fmt rgb8, then you can probably submit a patch [11:44] <BBB> Compn: duplicate code isn't a great idea, I think splitting decoders is fine but put common code in a shared file (header if you want to inline it)... but *effort* [11:44] <pippin> ubitux: I am checking that now,. and to do that I have started a gasoline powered generator :] [11:45] <Compn> coding off a generator :D [11:46] <BBB> too bad pross isn't here [11:47] <pippin> while coding/idle my laptop uses ~8 watts; big compiles are best done while charging [11:47] <BBB> michaelni: if it makes any difference, I'm still fine with merging vp7 as-is (I'd prefer pross was here, but ohwell) [11:50] <Compn> better to commit without waiting for pross [11:50] <Compn> hes busy [11:51] <Compn> i bugged him about bayer patch for years :) [11:51] <pippin> ubitux: with -pix_fmt rgb8 # it works [11:52] <pippin> ubitux: and then the question might be, if having to force the format for bayer (and my two methods) is a regression or not. [11:52] <ubitux> it's unreleated [12:13] <pippin> ubitux: thank you for your help - now the people that want to encode GIF anims with those methods can use master + the patch :) [12:19] <ubitux> would be nice if they could just have to use master [12:59] <michaelni> BBB, IIRC i didnt apply as i read the last mail from you as a question (about the 0.25%) and so waited ... [12:59] <michaelni> ill check if the patches still apply [13:15] <BBB> michaelni: hm, I see... no I think 0.25% is fine [13:21] <michaelni> ok, seems they still apply [13:31] <cone-700> ffmpeg.git 03Peter Ross 07master:7d4c0220f18a: avcodec/vp8: vp8_find_free_buffer [13:31] <cone-700> ffmpeg.git 03Peter Ross 07master:89f2f5dbd7a2: On2 VP7 decoder [13:31] <cone-700> ffmpeg.git 03Peter Ross 07master:4a031ce3c634: avformat/riff: add On2 VP7 fourccs [13:31] <cone-700> ffmpeg.git 03Peter Ross 07master:a490970af2f0: libavcodec/*/vp8dsp_init: indent [13:35] <michaelni> pippin, about the patch [13:35] <michaelni> theres "fprintf (stderr, "eeek1\n");" in it [13:36] <michaelni> and fprintf (stderr, "eeek2\n"); [13:58] <cone-700> ffmpeg.git 03Øyvind Kolås 07master:3e6016622e6f: swscale: add two spatially stable dithering methods [13:59] <ubitux> cool :) [14:06] <michaelni> any other patches that where "forgotten" and should be applied ? [14:22] <pippin> michaelni: \o/, I was about to fix up the patch by removing both the default and auto cases; other parts of the code should ensure that neither ever is the case. [14:43] <Daemon404> i see someone added GDI screen grabbing (cool) [14:43] <Daemon404> maybe ill go ahead and add the new (way, way better) screen grab API [14:43] <Daemon404> (win8+ only though) [14:45] <JEEBsv> yeah, the D3D 11 one seems rather naisu [14:46] <Daemon404> it is [14:50] <wm4> and who adds D3D output` [14:51] <wm4> ? [14:51] <Daemon404> output? [14:51] <Daemon404> it's input [14:52] <Daemon404> you get frames. [14:53] <wm4> Daemon404: I know [14:53] <wm4> but libavdevice can do output too now [14:53] <Daemon404> oh it was a trol [14:53] <Daemon404> nobody cares about output [14:53] <Daemon404> maybe one guy. [14:53] <wm4> hue [14:54] <wm4> that's almost mean [14:54] <Daemon404> but is it unture? [14:54] <Daemon404> untrue* [14:55] <Daemon404> www.virtualdub.org/blog/pivot/entry.php?id=356 [14:55] <Daemon404> what i was refering to btw ^ [14:55] <Daemon404> could is there to look at in vdub too [14:56] <Daemon404> it works really well [14:56] <kierank> Daemon404: wow gabest replies in that thread [14:57] <av500> oh, virtualdub [14:57] <Daemon404> kierank, gabest regularily replies to avery lee's posts [14:57] <JEEBsv> yeah [14:57] <Daemon404> also <3 avery lee [14:57] <JEEBsv> aye <3 [14:57] <av500> +1 [14:57] <av500> once he fixed vdub for me :) [14:57] <Daemon404> lol [14:58] Action: kierank used nandub [14:58] <av500> actually, I sent him a patch [15:02] <Daemon404> kierank, nandub has been irrelevant since the divx 3.11 days [15:02] <Daemon404> sorry [15:02] <Daemon404> divx .11 ;-) [15:02] <Daemon404> s/ [15:02] <kierank> I am aware of that [15:03] <Daemon404> ... ill stop typing now. [15:08] <ubitux> kierank: gpu encode? :( [15:08] <kierank> where [15:09] <ubitux> i don't know i'm waiting for your writeup [15:09] <ubitux> someone asked me [15:10] <kierank> I forgot about that [15:10] <kierank> I need time [15:10] <ubitux> asking me about stuff like https://developer.nvidia.com/nvidia-video-codec-sdk [15:10] <kierank> ubitux: tthat is different [15:10] <ubitux> and i must say i have not enough experience to know what to say [15:10] <kierank> GPU encoding and GPGPU encoding are not the same [15:11] <kierank> the former is just a hardware encoder on teh gpu [15:11] <kierank> the latter is using algorithms running on the main gpu [15:14] <ubitux> i'd really love an article anyway :° [15:14] <ubitux> i need to motivate myself to write something about the subtitles [15:14] <ubitux> wm4: you think you're going to be able to do sth about utf16? [15:14] <kierank> I need to start hacking on the dvbsub encoder [15:15] <ubitux> we need to move the subs to lavu and inject them into libavfilter :( [15:20] <wm4> ubitux: yes but tomorrow [16:56] <cone-700> ffmpeg.git 03Carl Eugen Hoyos 07master:e6fe804bdd62: Do not set swscale sizeFactor to -1. [16:56] <cone-700> ffmpeg.git 03Carl Eugen Hoyos 07master:0816abae1ed1: Add an .oga muxer. [17:52] <cone-517> ffmpeg.git 03rogerdpack 07master:10056bc964f7: dshow: log error and continue if unable to set audio buffer [18:02] <cone-517> ffmpeg.git 03rogerdpack 07master:4d9881e1cc20: udp: mention default in documentation [18:02] <cone-517> ffmpeg.git 03James Almer 07master:2d9821a2081a: x86/cpu: check for OS support before enabling AVX2 [18:30] <llogan> kierank: did you see if emotion fixed things as they claimed? i'll close the ticket if they did. https://trac.ffmpeg.org/ticket/3454 [18:32] <kierank> oh forgot about that [18:32] <kierank> i'll look when i am at home [19:25] <cone-517> ffmpeg.git 03Vittorio Giovara 07master:6ee55c7b111e: vf_transpose: K&R formatting cosmetics [19:25] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:10e931d51477: Merge commit '6ee55c7b111eec6c51dfdc0fddbd46f5dd867fa3' [19:39] <cone-517> ffmpeg.git 03Vittorio Giovara 07master:aa499568afc0: avconv: More descriptive message about framedrop [19:39] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:41e7e46cac50: Merge commit 'aa499568afc01d59215eef7e5b14b949a9671afc' [19:52] <cone-517> ffmpeg.git 03Vittorio Giovara 07master:dc0c70e018f6: avcodec: add missing includes [19:52] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:8f20e3d4dfe5: Merge remote-tracking branch 'qatar/master' [22:04] <kierank> llogan: seems to be fixed [00:00] --- Wed Mar 26 2014