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

[burek]

[00:42:45 CEST] <atomnuker> durandal_1707: huh, turns out our wavpack encoder isn't bad at all
[00:42:56 CEST] <atomnuker> but why is joint_stereo off by default?
[00:44:58 CEST] <durandal_1707> atomnuker: I think its still slower than cmd encoder
[00:45:24 CEST] <atomnuker> yeah, it's a bit slower than libwavpack (which isn't affected by the compression_level setting)
[00:45:37 CEST] <atomnuker> at compression_level 3 we match the size it produces exactly
[00:45:45 CEST] <atomnuker> but we're slightly slower
[00:45:57 CEST] <atomnuker> (with joint_stereo turned on)
[01:07:54 CEST] <Daemon404> ^ your favourite, kierank 
[01:08:09 CEST] <Shiz> w 27
[01:08:16 CEST] <Daemon404> exactly.
[01:09:22 CEST] <kierank> Omg
[01:15:33 CEST] <llogan> let's add a web browser too
[01:16:05 CEST] <Shiz> add ssl
[01:16:07 CEST] <Shiz> come one guys
[01:16:09 CEST] <Shiz> on*
[01:25:49 CEST] <Daemon404> ... we do
[01:25:59 CEST] <Daemon404> already.
[01:26:30 CEST] <RiCON> not with schannel
[01:26:39 CEST] <RiCON> iirc
[01:27:43 CEST] <Daemon404> yes but the rest.
[01:29:53 CEST] <llogan> wm4: typo in mpv docs for --lavfi-complex: "A label named ao will be connected to the audio input." s/input/output
[02:16:39 CEST] <cone-354> ffmpeg 03Christophe Gisquet 07master:9c1aa14bf0b8: vc2enc: prevent random data
[02:47:27 CEST] <cone-354> ffmpeg 03Muhammad Faiz 07master:83065939cb84: avutil/parsing: add '\r' as whitespace
[02:47:28 CEST] <cone-354> ffmpeg 03Muhammad Faiz 07master:1d4400ac7fb0: avfilter/graphparser: add '\r' as whitespace
[03:51:53 CEST] <cone-354> ffmpeg 03Andrey Utkin 07master:abb69a2f2ba8: avcodec: Add "sar" alias to "aspect" option of video encoders
[05:50:21 CEST] <cone-354> ffmpeg 03James Almer 07master:bd63ecec7820: avcodec/dcadsp: use LOCAL_ALIGNED_32 instead of LOCAL_ALIGNED(32, ...)
[06:47:58 CEST] <jya> is AVFrame::coded_picture_number only used by the h264 decoder?
[10:27:54 CEST] <cone-096> ffmpeg 03Timo Rothenpieler 07master:31ce01bdb972: avcodec/nvenc: don't set profile in lossless mode
[11:20:22 CEST] <BtbN> https://bpaste.net/show/357c0b6af51b great...
[11:22:45 CEST] <BtbN> aparently triggered by using -O3, -O2 works fine.
[11:22:48 CEST] <BtbN> gcc 5.3.0
[11:51:56 CEST] <iive> BtbN: nICE, 
[11:55:50 CEST] <nevcairiel> BtbN: its probably the tree vectorization which we turned on recently, imho that should just be reverted, its been producing errors in all kinds of scenarios
[12:07:14 CEST] <Daemon404> nevcairiel, i did warn against it! :)
[12:13:57 CEST] <JoshX> is it possible to store the systemtime as unix epoch in the videostream as secondary timecode in a matroska container?
[12:14:02 CEST] <Compn> gcc ".0" ...
[12:14:04 CEST] <JoshX> i know axis camera's do it
[12:14:21 CEST] <JoshX> so it is possible in the container
[12:14:26 CEST] <JoshX> now, can ffmpeg do it too ;)
[12:15:06 CEST] <JoshX> or if i would want to implement it myself, where to look in the code :-) i would like the current system timestamp in every keyframe for example... once per second is more than enough
[12:15:10 CEST] <nevcairiel> Compn: you should really have an idea what you are talking about before typing =p
[12:15:18 CEST] <Compn> JoshX : can probably write a script to dump systemtime to a timecode format and then ffmpeg can mux it
[12:15:38 CEST] <Compn> nevcairiel : yes, frequently gcc versions with .0 cause problems
[12:15:45 CEST] <Compn> gcc 5.0 4.0 etc
[12:15:51 CEST] <nevcairiel> but this is not a 0 version, its a 3 version
[12:16:10 CEST] <Compn> just means gcc is introducing that in its point releases too
[12:16:12 CEST] <nevcairiel> gcc 5.3 is the third release of the 5 series compiler
[12:16:15 CEST] <JoshX> Compn: i don't get it.. use the start time of the file as a 'start' and postprocess the timestamps in it?
[12:16:28 CEST] <nevcairiel> they dont use the third digit anymore
[12:17:11 CEST] <JoshX> i already patched ffmpeg to be able to produce filenames with the systemtime to the msec in it.. so i know the start time of each file..
[12:17:17 CEST] <Compn> fair enough
[12:18:33 CEST] <JoshX> I guess more people would want this feature :) to be able to, not only store the frame time, but also the actual time of recording
[12:18:36 CEST] <Compn> JoshX : sorry, i dont know :D
[12:25:43 CEST] <iive> nevcairiel: nevcairiel they don't use zero for development releases anymore either,
[12:25:50 CEST] <JoshX> well... there is this file: libavformat/mkvtimestamp_v2.c
[12:25:56 CEST] <iive> but 5.3.0 is before they did adopt all that
[12:25:57 CEST] <JoshX> perhaps i could do something here...
[12:26:11 CEST] <nevcairiel> iive: no its not, 5.x was the first of the new versioning scheme
[12:26:26 CEST] <nevcairiel> 5.0 was development, 5.1 the first release etc
[12:27:07 CEST] <nevcairiel> intermediate development versions use .1 at the end, so 5.3.1 is the latest development version of the 5 branch, once its released itll be 5.4
[12:27:56 CEST] <iive> hum... i've missed that
[12:28:22 CEST] <iive> and 5.3.1 been development version is horrible idea
[12:29:41 CEST] <nevcairiel> publicly they dont use the third digit at all anymore, all documentation etc only lists two
[12:30:01 CEST] <iive> they packaging and version strings still print it.
[12:31:18 CEST] <iive> however having 6.0 been development and then every version that doesn't end in 0 also been development, is quite inconsistent and conflicting.
[12:31:52 CEST] <jkqxz> Not doing so would defeat the point.  The whole change is because many distributions use random unreleased version versions of gcc, and they want to be able to identify those to tell people to go away / use a proper version.
[12:32:49 CEST] <iive> i don't see how this changes anything...
[12:33:19 CEST] <iive> i mean, isn't debian now 5.3.0-137.12 ?
[12:33:34 CEST] <iive> (i guess not, i just made it up ;)
[12:34:03 CEST] <jkqxz> Previously, people would claim to have version 4.6.0 or whatever and actually have some random early branch of that.  Now you can see from a version number like 5.0 that they are naughty.
[12:35:57 CEST] <nevcairiel> i suppose for consistency they might also call it 6.0.1 during development
[12:36:30 CEST] <mark4o> Just call it version N-78989-gcaeed04 :P
[12:36:35 CEST] <iive> yeh... that would be sensible
[13:15:30 CEST] <Daemon404> nevcairiel, nals? :x
[13:24:02 CEST] <Compn> mark4o : hey, "78989" is chronological at least :P
[13:25:50 CEST] <Compn> somewhat. depending on the merges.
[14:12:02 CEST] <Daemon404> act
[14:48:17 CEST] <durandal_1707> DSM_: hi
[15:47:11 CEST] <cone-746> ffmpeg 03Michael Niedermayer 07master:4155d5e06fa7: avcodec: add M101 decoder
[15:47:11 CEST] <cone-746> ffmpeg 03Michael Niedermayer 07master:5621da4996fe: avformat/riff: add M101
[15:50:17 CEST] <durandal_1707> michaelni: codec id is in wrong place
[16:00:46 CEST] <cone-746> ffmpeg 03Michael Niedermayer 07master:58b3e5606b99: avcodec/avcodec: Move AV_CODEC_ID_M101 to the 2nd group of video codecs
[16:30:55 CEST] <nevcairiel> Daemon404: i send a preparation patch to the ML
[16:53:36 CEST] <RiCON> basically, nothing new ^
[17:00:14 CEST] <wm4> I wonder if cehoyos enjoys his shit
[17:00:25 CEST] <wm4> because he's the maintainer of this thing now
[17:00:33 CEST] <wm4> everyone else wanted to remove it
[17:03:27 CEST] <Daemon404> nevcairiel, cool
[18:22:09 CEST] <nevcairiel> Daemon404: well i made it compile, if it passes fate .... :)
[18:30:06 CEST] <nevcairiel> wow it works
[18:30:11 CEST] <nevcairiel> (not on the first try)
[18:38:31 CEST] <durandal_1707> Daemon404: you merged hw upload / download filters?
[18:43:48 CEST] <nevcairiel> Daemon404: https://github.com/Nevcairiel/FFmpeg/tree/h264merge
[18:43:59 CEST] <nevcairiel> 3 top commits
[18:47:20 CEST] <nevcairiel> really wasnt that hard, instead of trying to merge the change i just re-applied it to our code, most of it is just re-indenting it one level and changing a few variables around
[18:48:58 CEST] <nevcairiel> git diff -w is surprisingly clean
[18:49:52 CEST] <nevcairiel> hm one hevc test broke by this, how odd
[18:49:53 CEST] Action: nevcairiel debugs
[18:52:40 CEST] <Daemon404> ill wait and merge when u give the ok
[18:52:50 CEST] <Daemon404> been working on a hobby project instead of merging
[18:53:18 CEST] <Daemon404> https://www.dropbox.com/s/w5a44jo7h8a4a0z/hexcmp.png?dl=0 <-- beyond compare style hex diffs of abritrarily different sized files
[18:53:25 CEST] <Daemon404> in cli
[18:55:37 CEST] <nevcairiel> there was a bug in ff_h2645_packet_split which initialized the getbitcontext with a value 8 times too high, when i fix that bug some hevc things fail their range checks
[18:56:09 CEST] <nevcairiel> without  fixing the bug, h264 doesnt work =p
[18:56:43 CEST] <Daemon404> oh good
[18:57:01 CEST] <nevcairiel> not sure if the check isnt maybe wrong
[19:08:02 CEST] <nevcairiel> i think the check was wrong
[19:11:26 CEST] <nevcairiel> Daemon404: how did your rebase those merges, i dont want to have to fix it again =p
[19:11:48 CEST] <Daemon404> as in how do i rebase merges when pople push?
[19:12:14 CEST] <nevcairiel> well or when i need to re-order a commit before it
[19:12:32 CEST] <nevcairiel> or well, i just pushed a new commit to https://github.com/Nevcairiel/FFmpeg/tree/h264merge .. it needs to go before the merge
[19:12:37 CEST] <Daemon404> for each merge: git diff <mergehash>^..<mergehash> > something.diff
[19:12:42 CEST] <Daemon404> and merge with -s orus
[19:12:46 CEST] <Daemon404> patch -p1 < something.diff
[19:12:49 CEST] <Daemon404> git commit -a --amend
[19:12:54 CEST] <Daemon404> old school
[19:13:03 CEST] <nevcairiel> i still wonder why git cant figure this our for you
[19:14:23 CEST] <Daemon404> i have no idea
[19:14:30 CEST] <Daemon404> im sure people will say rebasing merges is wrong
[19:15:18 CEST] <nevcairiel> i sent my latest fix to the ML just to be safe
[19:19:10 CEST] <nevcairiel> ok re-ordered in my branch
[19:24:05 CEST] <iive> nevcairiel: you don't ask for `git rebase -i <sha1>` i guess
[19:24:39 CEST] <nevcairiel> rebase doesnt like merges
[19:25:05 CEST] <iive> who does ;)
[19:45:34 CEST] <cone-091> ffmpeg 03Carl Eugen Hoyos 07master:017d42ebc60f: configure: Only utvideo <= 15.3.0 is supported.
[19:46:54 CEST] <RiCON> there, fixed.
[19:51:10 CEST] <wm4> "fixed"
[19:54:57 CEST] <kierank> hahahaha
[19:57:54 CEST] <JEEB> that's... one way of doing it
[19:58:10 CEST] <JEEB> considering nobody cares about libutvideo really, that might be for the better
[19:58:36 CEST] <JEEB> (although it wouldn't be really different to just removing the wrapper :D)
[19:59:42 CEST] <RiCON> wonder which obscure fork he used for >15.1.0
[19:59:52 CEST] <RiCON> since qyot's only goes up to that one
[20:05:40 CEST] <Daemon404> Not My Problem
[20:11:34 CEST] <jamrial> hah, that's a nice way to get around actually having to maintain the wrapper while still being able to pretend he maintains it
[23:55:00 CEST] <cone-350> ffmpeg 03James Almer 07master:03fceb771cee: fate: fix dcadec test dependencies
[00:00:00 CEST] --- Sat May  7 2016