[01:06] <cone-727> ffmpeg.git 03Michael Niedermayer 07master:ecd39520b83e: avcodec/h264: Partially decode and display single fields try #2 [03:46] <fffan> ./configure --toolchain=msvc --arch=x86 --enable-ffplay --enable-w32threads --enable-hwaccel=h264_dxva2 --enable-shared --disable-static [03:46] <fffan> I wanna build ffplay by visual studio 2013, but it does't output ffplay.exe [04:56] <cone-873> ffmpeg.git 03Michael Niedermayer 07master:b4f5da26517c: avutil/buffer: factor buffer_replace() out [05:31] <fffan> error D8021 Werror=missing-prototypes” [12:39] <cone-896> ffmpeg.git 03Martin Storsjö 07master:9108967513fc: rtspdec: Consistently use rtsp_hd_out for writing [12:39] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:0982077be563: Merge commit '9108967513fcaff3d55514a7bca4c9fbba128c71' [13:52] <j-b> 27 files changed, 2944 insertions(+), 111 deletions(-) [13:52] <j-b> wow, that's laarge patch [13:53] <j-b> and what's the goal of having both 608 and VBI in the same file? [13:55] <kierank> it's some guy's code dump [13:56] <Daemon404> :D [13:56] <kierank> "support in mpegts for Fortis OEM recordings with no PAT" [13:56] <kierank> eugh [13:57] <Daemon404> yum [13:57] <j-b> and why modify the avcodec and avformat code at the same stage? [13:58] <ubitux> you are asking why someone who never officially contributed to ffmpeg and kept a fork on its own for a long time is submitting a code with flaws? [13:59] <ubitux> the only reason he submitted it was probably because the addition of 608 caused him some conflict [13:59] <ubitux> and since it's starting to be hard for him to maintain it, so he's dumping his code in the hope we integrate it :p [14:01] <j-b> why the hell am I still @ here? [14:03] <Daemon404> i dunno; why am i? [14:05] <compn> contributers get op [14:05] <compn> why are you so upset about it ? [14:07] <Daemon404> im more of a troll than contributer usually [14:13] <cone-896> ffmpeg.git 03Jon Morley 07master:47372caac507: libavformat/mov.c: Handle timecode from tmcd atom in counter mode [14:14] <ubitux> so now people are now complaining about the +o they have [14:14] <bencoh> :D [14:14] <ubitux> seems our project is really perfect to have only this to complain about [14:51] <Daemon404> dvbsnoop is proving to be invaluable... [15:17] <compn> wm4 : you know by arguing about asm in vf_eq that you are slowing down things? :P i mean, who cares about a file you wont use? :P [15:17] <wm4> compn: if you had any clue of anything, you'd know the asm in vf_eq2 is exactly the same [15:19] <compn> nevermind, not important [15:22] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:579795b2049b: avfilter/af_channelmap: Check for missing argument in get_channel_idx() [15:22] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:8c8ee17e8d28: doc/APIchanges: fill in more missing hash values and dates [15:25] <compn> vbi patch depends on ass ? [15:25] <wm4> all subtitle decoders do [15:26] <compn> ah [15:27] <ubitux> we should still add a markup stripper to fill the text field [15:27] <ubitux> for those with their own text renderer [15:31] <ubitux> can we make an encoder taking different pixel format in input based on its AVOptions? [15:31] <ubitux> s/taking/take/ [15:32] <ubitux> or i need to make multiple encoders like libx264 and libx264rgb? [15:35] <wm4> here's a dumb ass markup stripper http://git.srsfckn.biz/mpv/tree/sub/sd_ass.c#n181 [15:38] <ubitux> good :) [15:38] <ubitux> gpl though [15:38] <ubitux> but yeah, sounds relatively easy [15:53] <wm4> ubitux: I wrote that, so it can be LGPL too [15:53] <ubitux> ok :) [16:12] <ubitux> oh, there is a text extension in gif [16:12] <ubitux> we could mux subtitles into gif! [16:13] <kepstin-laptop> needs formatting, to make sure that you get the correct outlined impact font. [16:13] <ubitux> don't worry about details [16:17] <wm4> there are extensions for anything [16:17] <wm4> the question is if something uses it [16:17] <wm4> e.g. I found lyrics in id3v2, but found no file which actually used them [16:17] <wm4> (timed lyrics) [16:19] <kepstin-laptop> i wouldn't be surprised if that's only been used in certain specialized, closed systems (karaoke?) [16:26] <ubitux> and after that, you put the gif into a subtitles file [16:26] <kepstin-laptop> yo dawg. [16:26] <ubitux> <img src="plaintexttroll.gif"> should do [16:27] <ubitux> or RLB plaintexttroll.gif in jacosub [17:31] <ubitux> i need to transmit a palette from the cli to the gif encoder (which will also transmit it to the gif muxer) [17:31] <ubitux> the encoder -> muxer should be fine with using extradata [17:31] <ubitux> but for the image into lavc it's a bit tricky [17:32] <ubitux> because i can't really load the palette from within the encoder (it requires libavformat to open the image file) [17:33] <wm4> side data! [17:34] <Daemon404> all of this is too slow. you should store it in the emu edges for non-mod16 images [17:34] Action: Daemon404 runs [17:37] <ubitux> well i probably need to pass through the AVOptions [17:38] <ubitux> but basically i can't have a -palette_file option in the encoder [17:39] <ubitux> if i need to do the palette image file ’ avoption, i could do it in ffmpeg.c [17:39] <ubitux> but well, that's a bit annoying [17:39] <ubitux> what do you suggest? [17:39] <iive> ubitux: theoretically, palette should be sent by each new image [17:39] <ubitux> no [17:40] <iive> as some formats support changing palette to simulate animation. [17:40] <ubitux> i know but that's not what i want to do here [17:40] <ubitux> i want an option to set the global palette [17:40] <ubitux> i don't want to use the local palettes [17:40] <ubitux> and that global palette is stored within an image [17:41] <ubitux> what i can do is take a 2nd "palette stream" within the muxer [17:41] <ubitux> but i then need to transmit that palette back to the encoder [17:41] <ubitux> while you can transmit from encoder to muxer through extradata, i'm not so sure about the other way around [17:42] <Daemon404> 1/g 31 [17:42] <ubitux> :( [17:43] Action: Daemon404 doesnt care; doesnt use pallettes [17:44] <ubitux> my plan here is to take the palette as text or binary option in the encoder (a "palette" text option) [17:44] <ubitux> and add a -gif_palette option in ffmpeg to open the file, and load it as an avoption [17:45] <ubitux> but dammit that sucks :( [17:45] <ubitux> the muxer can technically open the image and decode it (because lavf has a dep on lavc) [17:45] <ubitux> but then it needs to communicate with the encoder [17:46] <ubitux> that would be perfect.. [17:47] <ubitux> i guess i could just write the extradata in the muxer and read it from the encoder [17:47] <ubitux> but... i'm not sure it will work right .. [17:49] <wm4> send it with the first frame? [17:50] <ubitux> i'm trying to communicate from muxer to encoder here [17:51] <ubitux> because only the muxer can open the palette (because of lavf/lavc dep) [17:55] <wm4> just pass it as comma separated avoption string [17:56] <ubitux> yes that's what i was planning to do, but where do you do the open of the palette [17:56] <ubitux> i have a palettegen filter [17:56] <ubitux> you give it a stream, and at the end it outputs a palette (so you put it in a pal.png or whatever) [17:56] <ubitux> that way you can see it etc [17:57] <ubitux> now i need to feed it to the encoder, because the encoder needs to do a matching of the input data with the color of the provided palette [17:57] <ubitux> so where do i do this image ’ text conversion [17:57] <ubitux> ? [17:57] <ubitux> (text or bin or whatever) [17:58] <ubitux> i want to be able on the cli to specify a path to the palette file [17:58] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:d36e66bb2622: avformat/librtmp: Fix build with --disable-network --enable-librtmp [18:02] <ubitux> michaelni: any idea what is available to communicate information from muxer to codec? [18:04] <ubitux> like, codec init might be called before the muxer init [18:04] <ubitux> so i'm actually kind of doomed [18:06] <ubitux> anyway, i'll go for the opening of the picture into ffmpeg [18:06] <ubitux> :( [18:09] <michaelni> ubitux, i dont understand exactly what you are atrying to do, if you want to have a filter that calculates the palette at EOF then that filter can in a 2nd pass convert all images to AV_PIXFMT_PAL8 which will contain the palette naturally and be input to the encoder [18:09] <ubitux> mmh [18:11] <ubitux> so a filter that would open the palette, and create a PAL8 stream, and the gif encoder / muxer would assume it doesn't change? (and will have to wait for the first frame to output the global palette, which would be the first one?) [18:13] <michaelni> yes, was just a random idea [18:14] <ubitux> might work yeah [18:14] <ubitux> i suppose we don't have a PAL8 pixel format where the palette is not supposed to change? [18:15] <ubitux> oh well i'll do that [18:15] <ubitux> thank you [18:34] <ubitux> saste: do we have a filter that take 1 static image in an input stream? [18:34] <ubitux> (instead of lamely opening the image itself with lavf etc) [18:41] <saste> ubitux, movie? [18:42] <ubitux> no? [18:42] <ubitux> like removelogo you know [18:42] <ubitux> but taking a stream instead of a path to an image [18:43] <ubitux> there is haldclut filter taking a second stream like that, but it's not a single image [18:43] <ubitux> and i prefer that approach over calling lavf + lavc within lavfi [18:44] <ubitux> because it's pointless, i mean i can just query a picture from the stream and that's it [18:44] <saste> ubitux, ah I got it [18:45] <saste> ubitux, is that related to palette hacking? [18:45] <ubitux> yep [18:46] <ubitux> i'm creating a stream taking one palette in a picture and the video stream [18:46] <ubitux> and i was thinking of loading the palette picture through a simple input [18:47] <ubitux> ffmpeg -i in.mp4 -vf palettegen palette.png [18:47] <ubitux> ffmpeg -i in.mp4 -i palette.png -lavfi paletteuse out.gif [18:47] <ubitux> typically. [18:47] <saste> ubitux, yeah [18:47] <saste> ubitux, can I ask you why do you want to implement that? [18:47] <ubitux> (dammit paletteuse is very close to the word "shovel" in french) [18:48] <ubitux> saste: to output way better gif [18:48] <saste> I had something similar in mind, check my OPW lavfi task proposal [18:48] <ubitux> saste: http://b.pkh.me/old.gif ’ http://b.pkh.me/new.gif [18:48] <ubitux> (WIP, still huge size and varying palette etc) [18:49] <ubitux> saste: sorry... i will be done by the end of the week end [18:49] <ubitux> the palettegen is done, paletteuse should be soon [18:49] <ubitux> i'll probably submit on sunday or so [18:49] <saste> ubitux, why should I be sorry? I'm indeed happy about that :-) [18:49] <ubitux> ah, okay, i thought i was stealing the fun :) [18:50] <ubitux> so anyway, 2 streams sounds better than a weird file loading right? [18:50] <saste> ubitux, my idea was more related to making it possible things like, say use the same palette of this famous vangogh painting to render this image [18:51] <saste> ubitux, yes, and you did already that in your haldclut filter, no? [18:51] <ubitux> haldclut take a video stream :) [18:51] <ubitux> but yeah [18:51] <ubitux> it supports file as well [18:51] <saste> but, if you only need a single static image i don't consider using lavf utils so wicked [18:52] <saste> but having a stream is more flexible (and doesn't require to bloat deps) [18:52] <ubitux> well maybe later we want to have a changing palette over time ;) [18:52] <ubitux> but yeah [18:52] <ubitux> the problem is the dep [18:53] <ubitux> i actually forgot that dual input thing [18:53] <saste> changing palette over time sounds cool [18:53] <ubitux> dualinput thing + repeatlast option forced should do the trick [18:53] <ubitux> saste: actually no :) [18:53] <ubitux> i mean, if you create a per-frame palette [18:53] <ubitux> you get annoying rendering [18:53] <ubitux> like some kind of noisy blinking effect [18:54] <ubitux> but well yeah, we can imagine application of this [18:54] <ubitux> anyway, gonna do this [18:55] <saste> ubitux, are you restricting yourself to a given number of colors (say 256 colors palette)? [18:55] <ubitux> yes [18:55] <ubitux> 255 (+1) (i have an option to let the last entry transparent for gif re-use) [19:59] <John____> Hi, I'm interested in contributing to FFmpeg through OPW. Could anyone please guide me regarding where should I begin from? [20:37] <compn> John____ : sure [20:38] <compn> John____ : https://trac.ffmpeg.org/wiki/SponsoringPrograms/OPW/2014-12 [20:38] <compn> has some info [20:39] <compn> if you read that already and are here to "contact us" , the opw mentors might not be around at the moment [20:39] <compn> but if you leave the irc open, they may show up later [20:39] <compn> i dont know much about the opw so i dont want to make any bad guesses [20:44] <John____> Thanks @compn. I've cloned the codebase on my system. I'm looking for help regarding compilation and some small tasks to get aquainted with the job. [22:11] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:2a06c2a03e12: mpegvideo_enc: Draw edges on input for non-multiple of 16 resolutions [22:12] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:72d99c8c2647: avformat/dv: check av_malloc() return code [22:12] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:e40cdf8604f1: Merge commit '2a06c2a03e1205aaeede5af850b9271752ddd4cf' [22:27] <cone-896> ffmpeg.git 03Vittorio Giovara 07master:4c5fa628da09: mov: Do not compute negative SAR values [22:27] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:da304c529b65: Merge commit '4c5fa628da099dbb598c93bc4555b8733d2c3035' [22:38] <cone-896> ffmpeg.git 03Vittorio Giovara 07master:7915e6741dbe: hlsproto: Properly close avio buffer in case of error [22:38] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:0c00e734ef2b: Merge commit '7915e6741dbe1cf3a8781cead3e68a7666de14f4' [22:50] <compn> John____ : ah well then just ask your questions here or in #ffmpeg on compilation questions and someone will answer them :) [22:51] <compn> dont wait to ask for that :) [23:16] <cone-896> ffmpeg.git 03Vittorio Giovara 07master:3a6dfec864d5: segment: Check av_get_frame_filename() return value [23:16] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:a915b1daee3b: Merge commit '3a6dfec864d569c2d0a875e1a7466f51b00edb63' [00:00] --- Sat Jan 24 2015