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

burek burek021 at gmail.com
Tue Jul 7 02:05:03 CEST 2015


[00:05:16 CEST] <cone-828> ffmpeg 03James Almer 07master:e43ea1cbb213: doc/texi2pod: fix an unescaped left brace
[00:07:39 CEST] <cone-828> ffmpeg 03Carl Eugen Hoyos 07master:97fa0f37fee3: lavc/j2kenc: Enable yuv42x and yuv41x encoding.
[00:08:44 CEST] <wm4> and the example is open source?
[00:08:59 CEST] <nevcairiel> its probably not a FOSS license
[00:16:22 CEST] <philipl> it@
[00:16:28 CEST] <philipl> it's not.
[00:18:22 CEST] <philipl> we do thw same basic ops as the example
[00:19:49 CEST] <philipl> i wonder if its just ffmpeg overhead. how fast would raw to raw be?
[00:23:01 CEST] <cone-828> ffmpeg 03Marton Balint 07master:3a19fe004838: lavc/utils: remove redundant call to ff_init_buffer_info
[00:23:02 CEST] <cone-828> ffmpeg 03Marton Balint 07master:10b6a83fb3ad: lavc/utils: change add_metadata_from_side_data to accept avpacket
[00:24:26 CEST] <kierank> gah libav merges breaking my patches
[00:30:14 CEST] <durandal_1707> cehoyos: what software shows subsampled ffmpeg output?
[00:37:28 CEST] <cehoyos> Works fine here with FFmpeg
[00:37:41 CEST] <cehoyos> Michael fixed the decoding issue you found, I just tested it.
[00:39:48 CEST] <durandal_1707> what about others?
[00:40:30 CEST] <philipl> The example app writes directly from the nvenc output buffer to disk, so it saves the memcpy on the output side.
[00:40:36 CEST] <philipl> That's probably the biggest difference.
[00:48:14 CEST] <cehoyos> Which others?
[00:51:39 CEST] <durandal_1707> OpenEXR
[00:52:00 CEST] <durandal_1707> Forget that one
[00:52:29 CEST] <durandal_1707> libopenjpeg among others
[00:56:16 CEST] <cehoyos> Works fine here with libopenjpeg
[00:56:33 CEST] <cehoyos> --enable-libopenjpeg --disable-decoder=jpeg2000
[01:15:26 CEST] <cone-828> ffmpeg 03Marton Balint 07master:9476c4c67e68: lavc/utils: call add_metadata_from_side_data in ff_init_buffer_info
[01:15:27 CEST] <cone-828> ffmpeg 03Marton Balint 07master:859731d64271: lavc/utils: get rid of add_metadata_from_side_data forward declaration
[10:18:50 CEST] <j-b> 'morning
[10:24:04 CEST] <durandal_170> 'morning
[11:35:00 CEST] <kierank> lglinskih_: ping
[12:29:13 CEST] <durandal_170> wtf now I get michaelni mails in spam
[12:30:02 CEST] <durandal_170> and wm4's but that is ok :-/
[12:34:47 CEST] <michaelni> durandal_170, any idea why ?
[12:37:05 CEST] <durandal_170> maybe someone who subscribed to -devel is reporting messages as spam, maybe even my...
[12:51:20 CEST] <lglinskih> kierank: hi!
[12:51:25 CEST] <kierank> hi
[13:04:02 CEST] <TimNich> durandal_170 Maybe because the mails are coming from a different box that claims to be the same box as before, and something thinks the id is being forged
[13:09:52 CEST] <lglinskih> kierank: my seek test is on ml now, yesterday I started to think about draw_horiz_band
[13:11:06 CEST] <lglinskih> But I didn't understand how to test it =\ 
[13:16:13 CEST] <nevcairiel> draw_horiz_band is evil
[13:26:05 CEST] <kierank> lglinskih: basically decode the frame as normal
[13:26:11 CEST] <kierank> then decode with draw horiz band into a buffer
[13:26:13 CEST] <kierank> then compare
[13:26:31 CEST] <kierank> wm4: do you have any other tests you want to see?
[13:29:44 CEST] <wm4> the seek test could be made more elaborate
[13:30:02 CEST] <wm4> outside of this, I currently can't think of anything (let's blame the heat)
[13:31:30 CEST] <kierank> other api users ping
[13:31:33 CEST] <kierank> what things do you want tested
[15:24:46 CEST] <michaelni> nevcairiel, are you ok with Ivan Uskovs patch with CODEC_FLAG_INTERLACED_DCT ?
[15:25:11 CEST] <nevcairiel> I find it  a stupid way to signal it, but what do i care
[15:25:16 CEST] <nevcairiel> apparently other encoders use it as well
[15:26:06 CEST] <rcombs> I find interlacing a stupid way to signal video
[15:26:57 CEST] <michaelni> i hated interlacing until someone showed me a jpeg2000 stream that had interlacing using 6 instead of 2 fields
[15:27:45 CEST] <rcombs> huh?
[15:28:34 CEST] <michaelni> rcombs, yes, exactly, brilliant summary
[15:29:50 CEST] <rcombs> like, each field has 1/6th of the lines in a frame, and they're actually all taken at different times?
[15:30:08 CEST] <nevcairiel> that is just weird
[15:30:28 CEST] <nevcairiel> interlacing is an artifact of analog transmission, and we only have the one kind of interlacing
[15:30:56 CEST] <michaelni> rcombs, IIRC yes, but its a long time ago, i hope i never see that file again
[15:33:10 CEST] <thardin_> reminds me of when I read about some guy who wanted to up the line resolution in the analog era to HD levels using triple interlacing
[15:34:23 CEST] <rcombs> I mean, there's that JPEG thing that they call interlacing and I guess is sort of similar but not really
[15:37:21 CEST] <cone-184> ffmpeg 03Ivan Uskov 07master:38402754b977: libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.
[15:37:22 CEST] <cone-184> ffmpeg 03Kieran Kunhya 07master:8234f0e3b485: avcodec: Add support for Closed Caption export in h264
[15:56:05 CEST] <cone-184> ffmpeg 03Rodger Combs 07master:2375a85c36c4: ffmpeg_opt: allow the user to ignore unused stream maps
[17:06:22 CEST] <kierank> lol carl
[17:08:24 CEST] <durandal_170> whats funny?
[17:09:54 CEST] <nevcairiel> there is a lavfi filter which can extract and show the CC data, isnt there
[17:19:33 CEST] <nevcairiel> actually its not a filter, its built-in lavfi magic
[17:19:46 CEST] <nevcairiel> it takes the side-data and makes it a stream
[17:33:02 CEST] <D404|Ghetto> mmm
[17:50:16 CEST] <cone-184> ffmpeg 03Ivan Uskov 07master:115c14c3b664: libavcodec/qsvenc.c: A warning message when library will work at partial hardware acceleration.
[18:01:45 CEST] <Compn> yes, it turned out that apparently incorrectly Apple documented that format as Y416 in their api docs
[18:01:46 CEST] <Compn> lol
[18:04:07 CEST] <D404|Ghetto> i dont remember the pixel formats beign actually documented by apple
[18:04:15 CEST] <D404|Ghetto> other than the (now missing) ice floe docs
[18:04:44 CEST] <Compn> i cant remember many pix fmts being documented anywhere
[18:04:55 CEST] <Compn> i think a whitepaper for some 10bit codec had a bunch of them
[18:05:53 CEST] <Compn> aja kona codecs or newtek speedhq codec something
[18:11:27 CEST] <kierank> D404|Ghetto: Ice floe still exists
[18:12:32 CEST] <D404|Ghetto> i thought they took it down
[18:49:09 CEST] <cone-184> ffmpeg 03Shivraj Patil 07master:2f3f98af2b32: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for mpegvideoencdsp functions
[18:49:10 CEST] <cone-184> ffmpeg 03Shivraj Patil 07master:709bb45c660a: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for me_cmp functions
[19:15:05 CEST] <michaelni> atomnuker, btw, your commit messages could use a few more newlines ;)
[19:15:57 CEST] <michaelni> no big issue, i can add newlines but i think you are unaware of, that our commit messages should not have too long lines
[19:26:29 CEST] <cone-184> ffmpeg 03Michael Niedermayer 07master:a3a61d4663ab: avcodec/lpc: Fix lpc_apply_welch_window_c() for odd len
[19:32:07 CEST] <atomnuker> michaelni: thanks, will keep that in mind
[19:32:18 CEST] <atomnuker> just a bad habbit I picked up from using github too much
[21:18:05 CEST] <cone-184> ffmpeg 03hSÇ 07master:72aaca748847: avcodec: loongson remove useless macros in mipsfpu optimization
[21:33:51 CEST] <wm4> "Sorry! Services (Trac) are not available because of maintenance work."
[21:34:47 CEST] <beastd> wm4: moving trac to new host
[21:48:20 CEST] <durandal_170> is anybody going to add ask to removegrain?, it shouldn't be hard
[21:48:32 CEST] <durandal_170> *asm
[21:49:38 CEST] <BtbN> I also still need to optimize the colorkey filter, and add a chromakey one. But i'm kinda short on time at the moment.
[21:50:08 CEST] <J_Darnley> durandal_170: any worthwhile code to copy in the original?
[21:51:20 CEST] <durandal_170> the original from vs  have some inline shit
[21:51:40 CEST] <J_Darnley> msvc only then?
[21:52:05 CEST] <J_Darnley> (at least it uses intel syntax)
[21:56:42 CEST] <J_Darnley> Wow, I do still have the version 1.0 package
[22:07:21 CEST] <Compn> cehoyos : not sure if you are interested, but i've uploaded a bunch of win32 mplayer binaries (2004-2015) for testing regressions, http://www1.mplayerhq.hu/~compn/mplayer-archive/ 
[22:07:35 CEST] <cehoyos> What for?
[22:07:53 CEST] <Compn> to get them off my failing harddrive
[22:07:56 CEST] <Compn> :)
[22:09:21 CEST] <Compn> no i dont have source, i'm breaking gpl oh noes
[22:10:14 CEST] <durandal_170> there are no regressions!
[22:14:30 CEST] <cehoyos> There are many regressions, but binaries are only useful for a quick start, they don't help without bisection imo.
[22:16:07 CEST] <durandal_170> regressions should be reported on trac, how many of them are currently?
[22:36:43 CEST] <podman> hey, have you guys found a new host yet?
[22:38:07 CEST] <BtbN> most stuff, if not everything, is already moved.
[22:38:22 CEST] <podman> BtbN: oh, cool
[22:39:25 CEST] <podman> BtbN: i was discussing with my team if there was anything we could do to help but it looks like you're all set
[22:40:17 CEST] <BtbN> I'm not sure what the current situation is, best talk with michaelni about that.
[22:40:29 CEST] <BtbN> It was just kinda urgent, as the old servers got terminated today.
[22:41:18 CEST] <BtbN> There propably still is use for more servers ;)
[22:41:30 CEST] <podman> BtbN: yeah, that seems kind of crazy
[22:42:32 CEST] <podman> I think I'll have a difficult time convincing my team anyway. They're more concerned about what's in it for us :\
[22:46:20 CEST] <jamrial> gmail is sending most ffmpeg-devel emails to the spam folder
[22:46:27 CEST] <jamrial> it's much worse than a few days ago
[22:46:39 CEST] <BtbN> Can't you just tell it to stop doing that?
[22:47:08 CEST] <jamrial> i have been tagging every email as "not spam" since this started
[22:48:57 CEST] <Compn> its possible that our mail server
[22:49:01 CEST] <Compn> is on sorbs blacklist ip range ?
[22:49:04 CEST] <Compn> someone should check 
[22:49:42 CEST] <Compn> shared hosting companies usually are
[22:49:45 CEST] <Compn> so gmail following sorbs
[22:49:48 CEST] <Compn> ...
[22:51:02 CEST] <jamrial> a few days ago it was limited to emails from a couple domains (like googlemail.com as kierank mentioned). now it's filtering emails sent by michaelni and nicolas george as well
[22:52:55 CEST] <J_Darnley> jamrial: make a filter in gmail and set the option "never send to spam"
[22:54:28 CEST] <podman> make sure you check your DKIM and SPF records to make sure they were updated if you switched servers?
[22:54:46 CEST] <jamrial> "Received-SPF: softfail (google.com: domain of transitioning ffmpeg-devel-bounces at ffmpeg.org does not designate 2a01:4f8:120:506c::2 as permitted sender)"
[22:57:18 CEST] <rcombs> the DNS designates 192.190.173.45 and 178.63.43.86
[23:02:16 CEST] <podman> that's probably some of it
[23:02:36 CEST] <podman> mail deliverability is a fickle beast. 
[23:06:11 CEST] <michaelni> how is the SPF record supposed to look exactly to solve this ?
[23:09:33 CEST] <J_Darnley> durandal_170: did remove grain get pushed yet?
[23:10:41 CEST] <rcombs> michaelni: what servers should be able to send email for ffmpeg.org right now?
[23:10:48 CEST] <J_Darnley> apparently not yet
[23:11:15 CEST] <rcombs> or, more generally, what changed?
[23:11:44 CEST] <michaelni> rcombs, both of our servers ffbox0.ffmpeg.org and trac.ffmpeg.org at least
[23:12:23 CEST] <rcombs> michaelni: neither of those resolves to that IPv6 address
[23:12:24 CEST] <michaelni> what changed seems our new box has a ipv6 address too
[23:12:55 CEST] <rcombs> and 192.190.173.45 is apparently avserver.banki.hu; should that be able to send email from ffmpeg.org as well?
[23:13:22 CEST] <michaelni> rcombs, no that should not be needed anymore
[23:15:09 CEST] <michaelni> rcombs, maybe join ##ffmpeg-admin
[23:47:52 CEST] <michaelni> new SPF/TXT records from rcombs are in, please tell us if this doesnt solve the mail issue or tere are other issues
[00:00:00 CEST] --- Tue Jul  7 2015


More information about the Ffmpeg-devel-irc mailing list