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

[burek]

[00:03:36 CEST] <cone-433> ffmpeg 03Luca Barbato 07master:d09b4cce21cd: mpjpeg: Simplify using avio_printf
[00:03:37 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:2a33dc2cdf6d: Merge commit 'd09b4cce21cdad5ef2855698395ffd6e37445212'
[00:03:55 CEST] <jamrial> J_Darnley: pw_4 and pw_8 are in constants.c, and no need to do times 16 dw for pw_div9 unless you plan on adding avx2 ymm versions
[00:11:43 CEST] <durandal_1707> J_Darnley: I changed only clipping to uint8 instead of uint16 for single filter. And thinking about 16 bit support...
[00:12:20 CEST] <J_Darnley> I'm still working of your original patch so that hasn't changed the "reference" output
[00:13:25 CEST] <J_Darnley> jamrial: why would I not add avx2?
[00:13:29 CEST] <J_Darnley> I didn't start writing it because this machine doesn't have avx2 instructions but I should be able to test on my brother's fairly easily
[00:14:31 CEST] <J_Darnley> and I will look at using the existing constants
[00:15:41 CEST] <jamrial> cool then
[00:17:05 CEST] <durandal_1707> jamrial: will add fate tests tomorrow, feel free to beat me
[00:20:28 CEST] <cone-433> ffmpeg 03Frank Heckenbach 07master:161a301d4427: mpjpeg: Write the Content-length
[00:20:29 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:17498b70d8b7: Merge commit '161a301d44274645c2272855dac3e4664f935603'
[00:30:52 CEST] <cone-433> ffmpeg 03Luca Barbato 07master:c8b8271379b2: xcbgrab: Explicitly include xcb/shape.h
[00:30:53 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:fcc117af30bc: Merge commit 'c8b8271379b200c5c6fa89ca995f90f97f55c2c5'
[00:36:29 CEST] <capostrike93> Hello
[00:36:35 CEST] <capostrike93> i know this is for development only
[00:36:47 CEST] <capostrike93> but in the user channel noone can respond my question
[00:36:57 CEST] <capostrike93> i am trying to do mpeg dash with codec vp9
[00:37:14 CEST] <capostrike93> and i followed a guide from vp9 page http://wiki.webmproject.org/adaptive-streaming/instructions-to-playback-adaptive-webm-using-dash
[00:37:40 CEST] <capostrike93> but i am getting an error
[00:37:52 CEST] <capostrike93> i posted the error on ffmpeg forum
[00:37:53 CEST] <capostrike93> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2218
[00:38:01 CEST] <capostrike93> [webm_dash_manifest @ 0x4610fc0] Could not find codec parameters for stream 0 (Video: vp9, none, 1280x720): unspecified pixel format
[00:38:12 CEST] <capostrike93> PLEASE, someone can help me?
[00:40:46 CEST] <cone-433> ffmpeg 03Stian Selnes 07master:dc1de0b95883: h261: Set 'still image mode off' in picture header
[00:40:47 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:a137e50ee54c: Merge commit 'dc1de0b958836545339611e9c050a1d4fdded263'
[00:44:06 CEST] <llogan> capostrike93: you'll have to ask the ffmpeg-user mailing list
[00:58:01 CEST] <cone-433> ffmpeg 03Stian Selnes 07master:02b7c630875c: h261: Signal freeze picture release for intra frames
[00:58:02 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:edfcbf7c83cb: Merge commit '02b7c630875c0bc63cee5ec597aa33baf9bf4e20'
[01:07:08 CEST] <philipl> wm4: Man, it was easy to create the filter.
[01:09:11 CEST] <wm4> oh
[01:09:44 CEST] <durandal_1707> in libmpcodecs?
[01:13:04 CEST] <philipl> wm4: Works really nicely. Filter takes in a vdpau surface image, then spits out a regular one. mpv is able to apply its rotation detection logic automatically and it all works.
[01:14:04 CEST] <wm4> nice - still a bit expensive to rotate it in sw though
[01:14:30 CEST] <philipl> True, but of course it gives access to all the other potentially interesting filters.
[01:14:40 CEST] <philipl> 'accelerated' rotation is probably desirable as well.
[01:15:43 CEST] <wm4> although, I guess with --vo=oprngl, it's rotated on the gpu
[01:17:52 CEST] <philipl> Right.
[01:19:24 CEST] <philipl> The only limitation is that I don't think it's possible to detect the right output format. I think its ok to hard-code, as vdpau is always decoding to some 420 format or another, and it can output either yuv420p or nv12.
[01:19:49 CEST] <philipl> You don't know the video surface format until you have a surface, which means you can't alter query_format or reconfig
[01:20:21 CEST] <wm4> right, that sounds quite annoying
[01:21:05 CEST] <wm4> I've been thinking about removing the static filter chain configuration (since (I don't see any _real_ need for it)
[01:21:16 CEST] <wm4> but not sure when/if it will happen
[01:24:37 CEST] <philipl> I don't think it's a big deal in practice, given that no actual decoder outputs anything else. I guess at some point we'll see 422 and 444 decoders but can deal with that when the time comes.
[01:26:05 CEST] <wm4> is there no hw yet that outputs these formats? (just generally asking)
[01:26:36 CEST] <J_Darnley> What is the argument for bash to exit if a command fails?  I can't find it in the manual.
[01:26:59 CEST] <wm4> wasn't it set -e
[01:27:38 CEST] <philipl> wm4: Not yet. I don't think any applicable current gen hardware outputs 422 or 444. The vdpau API supports them but that's just theoretical right now.
[01:28:36 CEST] <wm4> I see
[01:28:39 CEST] <philipl> Technically, crystalhd outputs 422 but that's another story :-)
[01:30:25 CEST] <wm4> I've been wondering for what hw this crystalhd stuff is
[01:31:20 CEST] <philipl> It's a broadcom standalone decoder.
[01:31:36 CEST] <philipl> It was relevant for a while up until a couple of years ago.
[01:31:50 CEST] <philipl> Could stick a minipcie card into a laptop or appletv and get accelerated decoding.
[01:32:21 CEST] <philipl> As it was standalone, it was just read/write from standard memory, so no fancy output stuff.
[01:32:50 CEST] <philipl> And the library consumed full bitstreams so it didn't make sense to put under hwaccel. It looks like a normal library wrapper but the library talks to hardware.
[01:33:04 CEST] <wm4> yeah... I know ffmpeg has wrappers for it, but I've never heard of anyone using it
[01:33:06 CEST] <cone-433> ffmpeg 03Vittorio Giovara 07master:1761ab838c75: lavc: Deprecate avctx.rc_strategy
[01:33:07 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:4a2bcdb28b51: Merge commit '1761ab838c75223a6b97d8c0720d09275374c53d'
[01:33:26 CEST] <wm4> apple's stuff also outputs 422 btw.
[01:33:35 CEST] <wm4> but I think modern stuff actually prefers nv12
[01:33:38 CEST] <philipl> It was mainly used by 1st gen appletv people running xbmc/kodi
[01:34:14 CEST] <philipl> I wrote the ffmpeg wrapper for fun, but yeah, I doubt many people used it.
[01:34:22 CEST] <philipl> xbmc always had their own code for it
[01:34:50 CEST] <philipl> But as far as I can tell, mine was the only implementation that could handle interlaced content. :-)
[01:35:02 CEST] <philipl> The behaviour was nightmarish to say the least.
[01:35:25 CEST] <wm4> sounds like fun
[01:36:12 CEST] <philipl> I guess because it had its own bitstream parsing, it could get tripped up by packed b-frames and had inconsistent behaviour with respect to whether it would give you back single fields or field-pairs for interlaced stuff.
[01:39:48 CEST] <wm4> hm, I should check what the heck my mmal stuff does with interlaced video
[01:59:50 CEST] <philipl> wm4: pull request sent
[02:03:55 CEST] <wm4> philipl: thanks... I'm in bed and will look at it tomorrow
[02:19:11 CEST] <cone-433> ffmpeg 03compn 07master:0054d5ac02ea: avformat/movenc: fix mime-types in movenc.c
[02:27:22 CEST] <cone-433> ffmpeg 03Ivan Uskov 07master:b409748bc441: libavcodec/qsvenc.c: fix incorrect loop condition.
[03:47:27 CEST] <cone-433> ffmpeg 03Chris Watkins 07master:4f5c2e651a95: oggparsedirac: check return value of init_get_bits
[04:02:40 CEST] <cone-433> ffmpeg 03Anton Khirnov 07master:0e7c0ec344f5: lavf/hevc: pad the RBSP buffer as required by the bistream reader
[04:02:41 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:b457da4ce27c: Merge commit '0e7c0ec344f542e68e3cc9680e8d41dffeffdb4e'
[04:06:39 CEST] <cone-433> ffmpeg 03James Almer 07master:c11810166205: avcodev/libdcadec: implement request_channel_layout
[04:08:40 CEST] <Compn> that application/mp4 mime type seemed to come out of 2011 , anton commit
[04:10:29 CEST] <jamrial> it's apparently a valid mimetipe, but in only a few rare cases
[04:57:14 CEST] <cone-433> ffmpeg 03Anton Khirnov 07master:fd124d8357b1: hevc_ps: split the code for parsing the SPS and exporting it into the context
[04:57:15 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:1d4194e69696: Merge commit 'fd124d8357b1becfde3ac8d5e3320127cf97a5b7'
[04:57:16 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:1dacf26964c9: avcodec/hevc_ps: Do not return success on failures in ff_hevc_parse_sps()
[05:24:07 CEST] <cone-433> ffmpeg 03Anton Khirnov 07master:69ab9f53f901: hevc: split bitstream unescaping to a separate file
[05:24:08 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:07ae8fa20ef2: Merge commit '69ab9f53f901eac6a649e22d28cf093357870627'
[11:46:57 CEST] <cone-156> ffmpeg 03Anton Khirnov 07master:3a85397e8bb4: lavc: add Intel libmfx-based MPEG2 encoder
[11:46:57 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:96ee6b9962ec: Merge commit '3a85397e8bb477eb34678d9edc52893f57003226'
[11:46:57 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:587980eb7a1f: configure: Fix build without libmfx
[12:04:05 CEST] <[-T-]> where are these commits ?
[12:04:09 CEST] <[-T-]> i can't find them on Master
[12:09:59 CEST] <cone-156> ffmpeg 03Anton Khirnov 07master:66acb76bb049: lavc: add Intel libmfx-based HEVC encoder
[12:10:00 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:7871eb436167: Merge commit '66acb76bb0492b263215ca9b4d927a7be39ace02'
[12:10:01 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:7c502935ec6b: configure: Fix build without libmfx
[12:10:34 CEST] <[-T-]> ok there was just a delay
[12:18:43 CEST] <cone-156> ffmpeg 03Luca Barbato 07master:8fcd121b823c: doc: Use the succinct syntax for the channelmap example
[12:18:44 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:8d4460f1bbe9: Merge commit '8fcd121b823caeadbe7597c9ae9229f6f164f949'
[12:22:16 CEST] <wm4> [-T-]: you're probably using github, but that's only a mirror, not the main repo
[12:24:46 CEST] <cehoyos> michaelni: When encoding mjpeg yuv422p, vsample is set to 2-2-2. Is it possible with FFmpeg to encode with vsample 1-1-1 which is needed for rtp?
[12:27:33 CEST] <cone-156> ffmpeg 03Sebastien Zwickert 07master:40af330adf7f: avconv: vda: Unlock the pixel buffer once it is accessed
[12:27:34 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:7e85727b984a: Merge commit '40af330adf7fde8073271cf2b41ff9adc4c2bba9'
[12:37:33 CEST] <michaelni> cehoyos, no i dont think its supported ATM, it would require encoding in rows of 1 block instead of 2, did you check the RFC if this is mandatory for RTP ? 
[12:38:55 CEST] <cone-156> ffmpeg 03Henrik Gramner 07master:d1a6cb195f61: x86: Serialize rdtsc in read_time()
[12:38:56 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:2ecbf44f21c0: Merge commit 'd1a6cb195f610978ba5d2351e60f938f7f261d59'
[12:51:19 CEST] <cehoyos> Yes, the rfc requires rows of 1 block, you also see this in the current source of libavformat/rtpenc_jpeg.c lines 79ff
[12:51:22 CEST] <cone-156> ffmpeg 03Luca Barbato 07master:84b223cc6d6e: configure: Make the new qsv encoder depend on libmfx
[12:51:23 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:4a5074d7987e: Merge commit '84b223cc6d6ed4cc8bd295457a90f7c94a9dd784'
[12:56:49 CEST] <michaelni> cehoyos, ok then currently its not supported
[13:08:25 CEST] <cehoyos> Thanks for the confirmation!
[13:08:41 CEST] <michaelni> nevcairiel, do you have a comment/suggestion on ff_alloc_packet*() ?should i add a flag to all calls or can i apply the patch or you have some other suggestion?
[14:35:28 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:15893adbdb6a: avcodec/hevc_ps: Remove gotos from ff_hevc_parse_sps()
[14:42:29 CEST] <cehoyos> I don't know if this was already mentioned: https://blogs.gentoo.org/lu_zero/2015/07/09/my-fun-starts-now/
[14:49:02 CEST] <ubitux> > For me Debian had been no help and additional bourden.
[14:49:05 CEST] <ubitux> he's gonna get some friends
[14:50:29 CEST] <cehoyos> Do you think "random blogpost by people with more bias than anything" means you? I ask because I never found it biased enough (but actually quite balanced)...
[14:50:51 CEST] <ubitux> dunno, i don't really care
[14:51:35 CEST] <ubitux> i was only interested in the project being available for all users, and that's now the case so i'm happy now
[14:52:10 CEST] <cehoyos> I always imagined having a drink when this happens but instead I just went to cinema yesterday;-)
[14:52:38 CEST] <ubitux> you can do both at the same time
[14:52:53 CEST] <wm4> do you deny that ffmpeg takes credit for things libav did?
[14:53:09 CEST] <ubitux> not denying anything
[14:54:20 CEST] <ubitux> and i definitely don't want to restart a drama, so let's forget this and appreciate the situation as is
[14:56:17 CEST] <wm4> I still hoped the projects could merge (you can laugh at me now)
[14:56:46 CEST] <cehoyos> Would you say that you at any time tried to help a merge? (Not joking!)
[14:57:11 CEST] <wm4> I tried to help in my own way, which means I unintentionally insulted everyone as much as possible
[14:57:22 CEST] <cehoyos> I understand this point.
[14:58:00 CEST] <cehoyos> I don't understand "ffmpeg takes credit" above: There are many patches in avconv git that lack attribution to the original author: Do you think that is also true for FFmpeg or what do you mean?
[14:58:47 CEST] <ubitux> wm4: "merge" is possible; and i would guess that a good reason to do so is available now
[14:59:12 CEST] <wm4> Libav waited too long and they have no leverage anymore
[14:59:24 CEST] <wm4> so rather than peace it'd be annexation
[14:59:29 CEST] <D404|Ghetto> 14:49 <@ubitux> > For me Debian had been no help and additional bourden. <-- he's not wrong.
[14:59:39 CEST] <D404|Ghetto> much of the post is maadman rants mind you.
[14:59:40 CEST] <D404|Ghetto> but that is pretty true.
[14:59:54 CEST] <ubitux> D404|Ghetto: addition burden that kept the project used by many users..
[15:00:04 CEST] <wm4> I can understand complaining about having to maintain an ancient release
[15:00:11 CEST] <ubitux> so yeah sure, users are a burden, but after all that was the only users
[15:00:39 CEST] <ubitux> what is the project for if not its users?
[15:00:49 CEST] <ubitux> i mean, we're not talking about a pet project
[15:00:53 CEST] <ubitux> anyway..
[15:01:04 CEST] <D404|Ghetto> ubitux: i was mroe referring to the standard debian package maintainer behavior of bitching constantly and filing "bugs" like lena, while submitting no fixes
[15:01:16 CEST] <D404|Ghetto> this is not a libav/ffmpeg thing, just a lolpackagers thing
[15:01:32 CEST] <ubitux> he submitted a bunch of fixes lately (to both projects btw)
[15:01:39 CEST] <ubitux> important fixes btw
[15:01:48 CEST] <D404|Ghetto> 4 years later ;)
[15:01:53 CEST] <wm4> the Lena thing was dumb, but Andreas Cadhalpun submits to both MLs yes
[15:02:20 CEST] <D404|Ghetto> anyway my opinion stays the same: everyone everywhere are petty children
[15:02:22 CEST] <cehoyos> D404|Ghetto The Debian package maintainer in his case was a person who was necessary for the start of avconv, so I don't really understand...
[15:02:53 CEST] <cehoyos> Since FFmpeg is in Debian, several bugs were filed and fixed, so I am not sure what the issue is here.
[15:03:07 CEST] <cehoyos> (Fixed with help from Debian)
[15:03:43 CEST] <cehoyos> Were you talking about Andreas above?
[15:03:45 CEST] <ubitux> D404|Ghetto: the lena story was an exception
[15:03:54 CEST] <ubitux> and hey, we had a good laugh
[15:03:57 CEST] <ubitux> ;)
[15:04:06 CEST] <cehoyos> I don't think Luca meant him, or did he?
[15:04:24 CEST] <ubitux> who knows
[15:04:40 CEST] <ubitux> anyway, working together is simple now
[15:04:57 CEST] <cehoyos> Andreas definitely sends many patches, so he cannot be "while submitting no fixes"
[15:05:05 CEST] <wm4> working with who?
[15:05:15 CEST] <ubitux> with libav developers?
[15:05:39 CEST] <ubitux> or even other downstreams waiting for the situation to solve by itself
[15:05:48 CEST] <ubitux> -other
[15:06:00 CEST] <wm4> oh well, whatever
[15:06:19 CEST] <ubitux> yeah
[15:06:28 CEST] <wm4> I'm still hoping Libav will continue cleaning up the API, which could never be done in FFmpeg because nothing is ever deleted here
[15:12:08 CEST] <thardin> is there even a full grasp of which APIs are in use in which systems?
[15:12:14 CEST] <thardin> like say debian
[15:16:06 CEST] <Mavrik> Most desktop players on Debian and derivatives link to the APIs so they can provide optional restricted format downloads
[15:16:12 CEST] <Mavrik> Encoders not so much.
[15:17:10 CEST] <thardin> I'm more alluding to being able to simplify APIs with confidence instead of blindly breaking user programs
[15:17:48 CEST] <thardin> something which the C ecosystem seems to suck at
[15:22:35 CEST] <J_Darnley> Just change what you like and say to the users "screw you, we like this design" in a manner similar to gnome 3 or firefox 4, 29, and some future version.
[15:26:26 CEST] <thardin> right. egos abound when no one is paid
[15:27:16 CEST] <thardin> or I mean: my code is of course the best and most perfectest
[15:27:46 CEST] <cone-156> ffmpeg 03Jovan Zelincevic 07master:f497a9e84edb: libavcodec: Implementation of AAC_fixed_decoder (LC-module) [1/4]
[15:27:47 CEST] <cone-156> ffmpeg 03Jovan Zelincevic 07master:08be74ac8154: libavcodec: Implementation of AAC_fixed_decoder (LC-module) [2/4]
[15:27:48 CEST] <cone-156> ffmpeg 03Djordje Pesut 07master:b04f46cb4bc0: libavcodec: Implementation of AAC_fixed_decoder (LC-module) [3/4]
[15:27:49 CEST] <cone-156> ffmpeg 03Jovan Zelincevic 07master:f21b4472efb3: libavcodec: Implementation of AAC_fixed_decoder (LC-module) [4/4]
[15:28:55 CEST] <J_Darnley> Also sprinkle plenty of NIH on top!
[16:05:20 CEST] <wm4> <thardin> I'm more alluding to being able to simplify APIs with confidence instead of blindly breaking user programs <- IMO the main issue is downstreams using terrible hacks, and FFmpeg appeasing to them
[16:06:41 CEST] <D404|Ghetto> wm4: in the past i've noticed many of these terrible hacks are usually due to the public api being unclear or confusing, or being mplayer
[16:08:42 CEST] <wm4> definitely
[16:08:57 CEST] <wm4> I still see so many users on libav-user using stuff like AVPicture
[16:10:38 CEST] <D404|Ghetto> i think i have a leftover call to one such function
[16:10:48 CEST] <D404|Ghetto> for making a avframe int oa contiguous buffer
[16:10:49 CEST] <D404|Ghetto> or something
[16:43:36 CEST] <J_Darnley> git add -p
[16:43:46 CEST] <J_Darnley> ha wrong window
[16:45:06 CEST] <TimNich> glad m not the only one ;)
[16:53:24 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:7ee935ba5c29: avcodec/qsvenc_hevc: Attempt to fix error: too few arguments to function ff_hevc_extract_rbsp
[16:56:33 CEST] <klaxa> and here i am, typing out --patch every time even though there is a -p shorthand for that m(
[16:57:39 CEST] <J_Darnley> :)
[17:36:25 CEST] <Compn> cehoyos :  i think "credit" means using "libav" name instead of "qatar" for instance. ffmpeg also pulls from ffmbc once in a while or from other fffms or other forks too, but we dont make a point to specifically credit those forks either
[17:36:48 CEST] <Compn> because no one cares and its the same code? but i guess libav cares.
[17:37:27 CEST] <philipl> The changes are individually fully credited. That seems reasonable to me, but the relationship here is obviously unusual...
[17:37:40 CEST] <Compn> yes but i think they want project credit too
[17:37:49 CEST] <Compn> of course i have no idea, should ask lu_zero
[17:38:27 CEST] <philipl> Oh, for sure that's what he's asking for. Just not sure whether this is considered a legitimate issue in the wider open-source world.
[17:39:06 CEST] <D404|Ghetto> such pettiness
[17:39:08 CEST] <D404|Ghetto> from everyone
[17:39:28 CEST] <Compn> ah. i agree, no idea. but i have no problem if "libav.org" wants a credit/shoutout somewhere 
[17:39:40 CEST] <Compn> because i'm not petty, as D404|Ghetto suggests
[17:40:03 CEST] <Compn> i've asked them to submit patches for where they want to be credited...
[17:40:16 CEST] <Compn> multiple times over the years
[17:40:33 CEST] <Compn> but D404|Ghetto does not care about such things
[17:40:44 CEST] <Compn> he only makes generalizations and assumes the worst :P
[17:41:57 CEST] <D404|Ghetto> Compn: not you specifically
[17:42:00 CEST] <D404|Ghetto> certain people are
[17:42:03 CEST] <D404|Ghetto> *cough*cral*cough*
[17:42:04 CEST] <D404|Ghetto> carl*
[17:49:37 CEST] <Compn> we dont even have 'qatar' anymore
[17:49:37 CEST] <D404|Ghetto> ... great
[17:49:38 CEST] <Compn> derp
[17:49:43 CEST] <D404|Ghetto> now in addition to wm4 and andreas
[17:49:53 CEST] <D404|Ghetto> michael, carl, and nicholas randomly get put in my gmail spam
[17:50:02 CEST] <D404|Ghetto> they sure are making it great...
[17:50:12 CEST] <Compn> make filter to send everything ffmpeg-* to inbox
[17:50:23 CEST] <D404|Ghetto> i specifically whitelisted wm4 before
[17:50:26 CEST] <D404|Ghetto> and everything to the ML
[17:50:31 CEST] <D404|Ghetto> still puts it in spam occasionally
[17:50:44 CEST] <michaelni> D404|Ghetto, does it say why ?
[17:50:49 CEST] <D404|Ghetto> no
[17:51:00 CEST] <D404|Ghetto> e.g. most of nicolas' emails get through
[17:51:08 CEST] <D404|Ghetto> but the concatdec set didnt
[17:59:51 CEST] <wm4> lol google
[17:59:57 CEST] <wm4> or whatever is the issue
[18:03:50 CEST] <Compn> kodak hits the mailing list...
[18:08:46 CEST] <c_14> Re: email. I've noticed that recently started sending from an IPv6 address, but the v6 address isn't listed as the AAAA record for the MX and doesn't have an RDNS record
[18:08:58 CEST] <c_14> *recently the mailing list server
[18:09:34 CEST] <c_14> I personally refuse mail like that, might be that gmail accepts it but increases the spam counter.
[18:12:07 CEST] <nevcairiel> the address is marked as valid in SPF, that should overrule misguided DNS things
[18:13:43 CEST] <nevcairiel> but someone might create an AAAA for that anyway
[18:16:09 CEST] <michaelni> what _exact_ records should i add for mail to be happy ?
[18:18:41 CEST] <nevcairiel> an AAAA record for the v6 of the list server, so probably ffbox0.ffmpeg.org and ffbox0.mplayerhq.hu (since it seems to be using both names) to 2a01:4f8:120:506c::2
[18:18:50 CEST] <nevcairiel> practically, have a AAAA record for every A record you also have
[18:23:25 CEST] <michaelni> that would break most services as they do not listen to ipv6 it seems
[18:23:43 CEST] <nevcairiel> either setup ipv6 for all services, or disable v6 entirely on the system
[18:23:52 CEST] <nevcairiel> it using v6 for outgoing connections on mail can confuse things
[18:24:06 CEST] <michaelni> yes ill probably disable it
[18:24:46 CEST] <Compn> michaelni : odd donation mail on mplayer-dev-eng, i cc'd it to root at mphq .
[18:27:01 CEST] <michaelni> disabled ipv6 for mail, please tell me if issues persist
[18:29:03 CEST] Action: Compn grumbles about emails titled "donation" amongst a sea of "donation" spam emails
[18:29:14 CEST] <Compn> can you believe i picked it out?? :D
[18:29:51 CEST] <J_Darnley> Did it lack all sorts of strange unicode characters?
[18:30:50 CEST] <Compn> J_Darnley : http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2015-June/072975.html
[18:32:06 CEST] <J_Darnley> oh it does have 1: an e with an acute accent
[18:32:42 CEST] <Compn> annoying that mailman sticks an old mail into the correct month archive :\
[18:32:52 CEST] <Compn> even if approved in july it shows up in june :\
[18:33:35 CEST] <J_Darnley> But the date in the header is absolute and unfalsifiable!
[18:34:06 CEST] <Compn> still have a mail that was sent in the year 2020 sitting there :D
[18:34:09 CEST] <J_Darnley> Why would you want anything else to happen?
[18:34:23 CEST] <Compn> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2022-December/013967.html
[18:34:25 CEST] <Compn> er 2022 *
[18:34:54 CEST] <J_Darnley> Argh!  Time traveller!  What's the future like?
[18:35:17 CEST] <Compn> wonder if mplayer will still be playing files that far into the future
[18:40:22 CEST] <cone-156> ffmpeg 03Ivan Uskov 07master:dbf8352a2e87: libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.
[19:00:21 CEST] <ubitux> WARNING: Option --enable-muxer=pcm did not match anything
[19:00:24 CEST] <ubitux> WARNING: Option --enable-muxer=s16le did not match anything
[19:00:26 CEST] <ubitux> :( :( :(
[19:00:47 CEST] <wm4> who needs pcm
[19:01:02 CEST] <ubitux> ah, it's pcm_s16le heh
[19:01:57 CEST] <Rathann> hello #ffmpeg-devel :)
[19:02:11 CEST] <Rathann> congratulations on getting back as default in Debian
[19:02:47 CEST] <ubitux> wm4: 2b3e9bbfb529e6bde238aeb511b55ebe461664c8 affects the pcm output, is this expected?
[19:02:54 CEST] Action: Rathann saw the news on LWN
[19:03:27 CEST] <wm4> ubitux: hm, not really
[19:03:55 CEST] <wm4> ubitux: but who knows what's going on in the rest of the chain with the junk added
[19:04:57 CEST] <ubitux> http://b.pkh.me/audio.mp3
[19:05:38 CEST] <ubitux> ./ffmpeg -i /tmp/audio.mp3 -f s16le ... 
[19:05:40 CEST] <ubitux> fa24a12f29dd54be32698c746ccb6e99  /tmp/post-commit.pcm
[19:05:41 CEST] <ubitux> 79646b6e35936a8031ecf2acddf1434c  /tmp/pre-commit.pcm
[19:05:47 CEST] <wm4> you can start with checking what the mp3 parser and decoder do with the junk data
[19:05:54 CEST] <ubitux> -rw-r--r-- 1 ux ux 149K Jul  9 19:01 /tmp/post-commit.pcm
[19:05:56 CEST] <ubitux> -rw-r--r-- 1 ux ux 151K Jul  9 19:01 /tmp/pre-commit.pcm
[19:09:24 CEST] <wm4> all in all this was a very confusing issue, because utils.c seriously started making shit up
[19:30:24 CEST] <durandal_1707> this aac_fixed decoder have serious warnings
[19:31:13 CEST] <Compn> so many patch reviews for it
[19:31:20 CEST] <Compn> fix it in git (please oh please)
[19:32:26 CEST] <Compn> i wonder if it was based on one of those rockbox codecs (which were based on old old lavc)
[19:37:01 CEST] <kurosu> The imgtec guys didn't check much their fixed point eac3 code, seeing how it crashed
[19:37:40 CEST] <kurosu> those versions should probably be disabled by default, just for the security aspect
[19:39:08 CEST] <cehoyos> Compn: "qatar" was chosen by them and it was very, very important for bisecting when they were still active. But how is that related to "credit"? And how does using the name "qatar" allow them to violate copyrights?
[19:39:27 CEST] <cehoyos> Pulling from ffmbc seems difficult (and does not happen) becaues its license is incompatible.
[19:41:50 CEST] <wm4> qatar was an april fools joke on their website, the branch was named by mini
[19:44:39 CEST] <cehoyos> wm4: Toi repeat myself: Stop using this insult both here and on the mailing list!
[19:45:13 CEST] <cehoyos> As said, without an identifiert bisecting would have been infinitely more difficult and we obviously didn't choose this one!
[19:46:20 CEST] <wm4> which insult?
[19:49:37 CEST] <J_Darnley> What is FFmpeg's policy on separate asm files for x86 and x86_64?  Is it common?  Is it desired rather than many "if ARCH_X86_64"?
[19:54:08 CEST] <Compn> cehoyos : sorry, qatar is gone so i shouldnt have used that as an example
[19:55:03 CEST] <Compn> cehoyos : its nothing to do with copyrights, they want recognition? i dunno ask lu_zero
[19:55:13 CEST] <Compn> i posted to his blog asking him for patches on how he wants credits to be made
[19:55:20 CEST] <Compn> my comment is moderated though
[19:55:22 CEST] <Compn> so who knows
[19:56:03 CEST] <Compn> wm4 : the "mini" thing is considered by some to be name calling
[19:56:28 CEST] <wm4> "some"
[19:56:37 CEST] <wm4> I've never seen mini complain about it
[19:56:53 CEST] <wm4> and "Michael Niedermayer" is way too long (did I even spell it correctly)
[19:57:10 CEST] <Compn> make all the excuses you want
[19:57:31 CEST] <Compn> i just dont see you (or anyone else in the projects) refer to anyone else by that name shortening schema...
[19:58:35 CEST] <wm4> and that's why it's insulting?
[19:59:02 CEST] <Compn> it might be that "mini" is an english word meaning small
[19:59:02 CEST] <ubitux> (i think he prefers "mn" or "michaelni")
[19:59:19 CEST] <ubitux> (i remember him telling that at least once)
[19:59:26 CEST] <Compn> which would make calling someone 'small' all of the time, an insult. but i a mnot linguistics expert :P
[19:59:32 CEST] <jamrial> J_Darnley: it's never been done. every file just uses preprocessor checks like the one you mentioned
[20:00:05 CEST] <J_Darnley> oh ok
[20:00:23 CEST] <wm4> Compn: you certainly aren't a linguistic expert, or an expert in anything
[20:00:37 CEST] <wm4> if mini says he doesn't like mini, I'll stop using it
[20:03:20 CEST] <ubitux> wm4: http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/191157
[20:04:14 CEST] <wm4> some sort of optimization advice
[20:04:57 CEST] <Compn> michaelni : ping, wm4 would like to know if "mini" name bugs you / if you want to be called something else
[20:05:06 CEST] <cehoyos> Then use michaelni
[20:05:32 CEST] <Compn> otherwise carl may take offense and this is already too distracting from developing...
[20:06:09 CEST] <cehoyos> I am not taking offense, I am just stating (repeatedly) that wm4 is using a name that was invented as an insult.
[20:06:29 CEST] <cehoyos> michaelni: Please merge from github the rtp, mkv and benchmark patches, thanks!
[20:06:41 CEST] <Compn> fair enough :)
[20:07:56 CEST] <cehoyos> ubitux: Very nice catch;-)
[20:08:46 CEST] <ubitux> iirc it was related to "minicycle"
[20:08:55 CEST] <ubitux> but anyway, we should probably move on to more interesting topics
[20:11:05 CEST] <Compn> yes like insulting compn :)
[20:11:12 CEST] <Compn> i am the worst, you all know it. 
[20:14:41 CEST] <ubitux> wm4: http://ubitux.fr/pub/pics/_after-before-2b3e9bbf.png
[20:15:33 CEST] <cone-156> ffmpeg 03Carl Eugen Hoyos 07master:da46370e94aa: lavf/matroskaenc: Do not needlessly allocate memory for cuepoints.
[20:15:34 CEST] <cone-156> ffmpeg 03Carl Eugen Hoyos 07master:6253f511e053: Cosmetics: Reindent after last commit.
[20:15:34 CEST] <cone-156> ffmpeg 03Carl Eugen Hoyos 07master:2c7f7a690fb4: ffmpeg: Use av_log to print benchmark output.
[20:15:34 CEST] <cone-156> ffmpeg 03Carl Eugen Hoyos 07master:ad7c5cba4ee9: lavf/rtpenc_jpeg: Do not check the table number when checking precision.
[20:15:34 CEST] <cone-156> ffmpeg 03Carl Eugen Hoyos 07master:e786e96be70a: lavf/rtpenc_jpeg: Error out for non-standard Huffman tables.
[20:16:27 CEST] <ubitux> wm4: it looks like some kind of weird stretching of some sort
[20:17:01 CEST] <wm4> isn't it just an offset?
[20:17:26 CEST] <wm4> why are you still on this, did it actually break something?
[20:17:47 CEST] <wm4> of course there's a behavior change, but to the better
[20:18:02 CEST] <ubitux> i'm just curious
[20:18:31 CEST] <ubitux> it broke a regression test at my company, so i was just wondering what was causing this
[20:20:33 CEST] <ubitux> it might be because there was silence inserted before
[20:20:43 CEST] <ubitux> (in place of the junk?)
[20:21:06 CEST] <ubitux> which would have impacted a bit the fft of the rest of the track
[20:28:22 CEST] <durandal_1707> ubitux: use showwavespic instead
[20:28:55 CEST] <ubitux> durandal_1707: yeah, true :)
[20:30:25 CEST] <ubitux> durandal_1707: Assertion b >=0 failed at libavutil/mathematics.c:67
[20:30:27 CEST] <ubitux> :(
[20:30:37 CEST] <ubitux> ah wait old version
[20:32:37 CEST] <ubitux> durandal_1707: http://b.pkh.me/after-before-2b3e9bbf.png
[20:34:32 CEST] <ubitux> http://b.pkh.me/after-before-2b3e9bbf-large.png
[20:34:59 CEST] <ubitux> that silence at the beginning is probably the cause of all of this
[20:35:13 CEST] <cone-156> ffmpeg 03Paul B Mahol 07master:ba0b4e53a534: fate: add removegrain tests
[20:35:46 CEST] <ubitux> it's interesting how it seems to impact the rest of the wave
[20:36:22 CEST] <ubitux> still wondering if it's because of different averaging samples and/or the impact on the decoding 
[20:42:05 CEST] <ubitux> (for the record; i used ffmpeg -i before.wav -i after.wav -lavfi "[0:0] showwavespic=s=4096x300, pad=h=ih*2 [a]; [1:0] showwavespic=s=4096x300 [b]; [a][b] overlay=y=h" -y after-before-2b3e9bbf-large.png
[20:42:07 CEST] <ubitux> )
[20:42:11 CEST] <ubitux> (and ffmpeg is awesome)
[20:42:36 CEST] <ubitux> 'could use [0] and [1] btw
[20:45:23 CEST] <cehoyos> ubitux: Is the removed part "sound" or "noise"?
[20:46:11 CEST] <ubitux> it looks like complete silence (0)
[20:55:18 CEST] <cehoyos> Then I apparently completely misunderstand the png you posted...
[20:57:43 CEST] <wm4> <ubitux> (and ffmpeg is awesome) <- except the weird syntax of course
[20:57:45 CEST] Action: wm4 hides
[20:58:07 CEST] <ubitux> that syntax is perfect ;)
[21:08:13 CEST] <ubitux> cehoyos: first wave is before the commit, 2nd wave is after the commit
[21:08:32 CEST] <ubitux> in the first wave you have a silence glitch at the beginning
[21:09:15 CEST] <ubitux> (look at the -large version)
[21:29:23 CEST] <cehoyos> ubitux: The "glitch" is not silent afaict: It looks as if there is some noise that shouldn't be there. (But perhaps it actually is sound)
[21:30:33 CEST] <ubitux> feel free to investigate, i'll trust wm4 on this one
[21:32:19 CEST] <wm4> you might also use tools like mpg123, and see what they do
[21:33:14 CEST] <cehoyos> But I agree with him...
[21:33:21 CEST] <cehoyos> (Visually, I didn't test the sample)
[22:07:20 CEST] <J_Darnley> neat, a palindrome: 530035
[22:31:32 CEST] <J_Darnley> jamrial or anyone else: are we allowed to use constants from lavc in lavfi?
[22:32:04 CEST] <J_Darnley> Didn't I see some messages a long time ago about some systems not liking this dependance between libraries?
[22:32:43 CEST] <wm4> which constants?
[22:33:16 CEST] <J_Darnley> ff_pw_4: packed 16-bit integers representing the value 4
[22:33:37 CEST] <BBB> Id just recreate the constants in lavfi
[22:33:39 CEST] <BBB> theyre not big
[22:33:41 CEST] <jamrial> right, forgot this was lavfi
[22:34:54 CEST] <J_Darnley> I also want to use pw_8
[22:34:55 CEST] <jamrial> ignore then my comment from yesterday, just leave them as is :p
[22:35:27 CEST] <J_Darnley> I can do that
[22:37:34 CEST] <J_Darnley> Later, I might also look into how many filters reuse constants and whether it valueable to copy the idea from lavc
[22:56:35 CEST] <cone-156> ffmpeg 03Michael Niedermayer 07master:b160fc290cf4: avcodec/mpegvideo: Clear pointers in ff_mpv_common_init()
[23:04:51 CEST] <BBB> J_Darnley: I think that would be cool
[23:05:00 CEST] <BBB> J_Darnley: even better if you could do it not in a c file, but in a asm file
[23:05:05 CEST] <BBB> (x264 does that, I believe)
[23:05:09 CEST] <BBB> since its much more readable
[23:05:20 CEST] <BBB> pw_8: times 8 dw 8
[23:05:21 CEST] <BBB> or so
[23:05:47 CEST] <BBB> and thne some magic to make it public and exported
[23:07:14 CEST] Action: J_Darnley nods
[00:00:00 CEST] --- Fri Jul 10 2015