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

[burek]

[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