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

[burek]

[00:00:21 CEST] <nevcairiel> j-b: qsvdec_mpeg2 isnt that much longer in libav either, although a bit logner indeed, but the common qsv code in theirs is just smarter
[00:00:42 CEST] <j-b> it's over 100LoC more
[00:00:56 CEST] <j-b> and it's actually doing stuff in flush
[00:00:56 CEST] <nevcairiel> yeah but thats only the input packet buffering
[00:01:30 CEST] <nevcairiel> the point is, all the hard work happens in common code for both decoders
[00:01:36 CEST] <nevcairiel> the one we have just is broken
[00:01:47 CEST] <wm4> I don't know qsv, but connecting the sync API with the async decoder was incredibly tricky with mmal
[00:01:50 CEST] <j-b> I mean, I wish the QSV API was that simple.
[00:01:53 CEST] Action: Daemon404 is so happy he doesnt use any hw stuff
[00:02:09 CEST] <j-b> but what I remember from the encoder in VLC, it was not. and it was very tricky.
[00:02:23 CEST] <j-b> maybe the decoder is really simpler, but I doubt it
[00:02:24 CEST] <michaelni> please report the issues to ivan, slandering him behind his back is completely destructive and wont solve anything
[00:03:05 CEST] <wm4> <Daemon404> [22:54] <+nevcairiel> i tried to review them
[00:03:05 CEST] <wm4> <Daemon404> [22:54] <+nevcairiel> but it was ignored
[00:03:26 CEST] <nevcairiel> i should actually build the latest code with qsv support and see how badly i can break things
[00:03:39 CEST] <nevcairiel> shouldnt be hard
[00:03:47 CEST] <michaelni> wm4, please ping the issues then if something was ignored
[00:04:58 CEST] <michaelni> nevcairiel, if you can test, please do and report (to the ML) what all is broken/not working
[00:05:06 CEST] <nevcairiel> In any case, should not merge more "decoders" from him until the issues with the core are resolves, i'll test and send a report tomorrow
[00:07:23 CEST] <nevcairiel> from the looks of it, a frame size change will likely result in a crash too
[00:07:29 CEST] <nevcairiel> but i'll test that tomorrow
[00:07:59 CEST] <michaelni> please do and take your time, i wont apply the mjpeg one till these questions are resolved
[01:47:05 CEST] <BBB> Gramner: re stack alignment change, its somewhat involved and I have to admit Im intrigued by it because I wrote the original version - is there a trivial explanation for what the changes are related to in general? is it just a different way of impleenting the same thing, or were there bugs in the original version?
[01:55:46 CEST] <cone-962> ffmpeg 03Emanuel Czirai 07master:7ab1c57a64b6: libavcodec/aacdec_template: Use init_get_bits8() in aac_decode_frame()
[01:55:47 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:7f46a641bf25: avcodec/aacdec: Fix integer overflow in argument to decode_audio_specific_config()
[03:40:54 CEST] <cone-962> ffmpeg 03Henrik Gramner 07master:f151fbd9e58c: x86inc: Disable vpbroadcastq workaround in newer yasm versions
[04:09:42 CEST] <cone-962> ffmpeg 03Henrik Gramner 07master:127203ba5a0b: x86inc: Various minor backports from x264
[04:59:03 CEST] <prelude2004c> hello .. looking for a good developer to incorporate verimatrix DRM into segmenter.c
[05:34:57 CEST] <prelude2004c> hey guys... need some asssistance
[05:35:03 CEST] <prelude2004c> anywhere around?
[05:35:14 CEST] <Compn> kinda
[05:35:18 CEST] <Compn> but sleeping now prelude2004c
[05:35:22 CEST] <prelude2004c> it relates to the segment outputs of ffmpeg..i did the segmenting and it looks right and generates the data correctly
[05:35:43 CEST] <Compn> prelude2004c : ask on the mailing list for devels, not all of them are on irc
[05:35:52 CEST] <prelude2004c> problem is .. i have 30 chunks ( 3 seconds each ) .. and when i playback through VLC it doesn't start at 00000.ts .. it jumps right to near end of the stream ( realtime ) 
[05:58:31 CEST] <prelude2004c> i am having a problem i can't seem to figure out... i have an index file ( m3u8 ) with 30 segments ( each with 3 second chunks ) .. eg.. file_0000001.ts , ..000002.ts, etc etc ..  for some reason everytime i pull up vlc
[05:58:32 CEST] <prelude2004c> and try to play the stream .. it starts up near the end or somewhere else but never at the first segment .. i don't undersatnd wh
[10:26:37 CEST] <cone-756> ffmpeg 03Sebastien Zwickert 07master:11d923d41412: avcodec: add new Videotoolbox hwaccel.
[10:40:37 CEST] <ubitux> anyone with a OSX knows where the "Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1" crap comes from when running configure?
[10:46:30 CEST] <Shiz> lessee
[10:46:58 CEST] <Shiz> i think it's gcc/clang
[10:48:00 CEST] <Shiz> ++ gcc --version
[10:48:01 CEST] <Shiz> ++ head -n1
[10:48:03 CEST] <Shiz> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
[10:48:05 CEST] <Shiz> sh -x is useful
[10:48:23 CEST] <Shiz> i'd suggest adding 2>/dev/null to the gcc --version invocation to make that useful
[10:48:37 CEST] <Shiz> it prints that configured line to stderr
[10:51:41 CEST] <ubitux> alright, thanks
[10:52:01 CEST] <ubitux> indeed i should have sh -x... derp
[10:52:20 CEST] <Shiz> line 3535 is where the change is needed
[10:52:33 CEST] <Shiz> in v2.7.2
[10:53:01 CEST] <ubitux> feeling like sending a patch? :)
[10:53:05 CEST] <Shiz> sure
[10:53:54 CEST] <ubitux> great, thanks
[12:22:09 CEST] <Shiz> posted
[12:32:48 CEST] <BBB> nevcairiel: could you test [PATCH 1/4] x86inc: Support arbitrary stack alignments on msvc-32bit?
[12:32:53 CEST] <BBB> (or anyone, for that matter)
[12:32:58 CEST] <BBB> if its tested, its ok
[12:33:34 CEST] <nevcairiel> in a couple hours
[14:19:23 CEST] <j-b> "seeking is broken" <= no way?
[14:21:21 CEST] <Compn> Daemon404 : bluray have 1080 mpeg2 last i checked.
[14:21:31 CEST] <nevcairiel> i was asked to document it on the ML, so i took the major issues and put them there, either it gets fixed now, or he'll disappear and we get to fix it ourselves =p
[14:22:13 CEST] <Compn> if you guys continue to harass NEW developers and would rather rm all of their work instead of fix it, you realize that we will never get any more new developers/contributors, right ?
[14:22:24 CEST] <Compn> j-b : really i expect better from you
[14:22:52 CEST] <Compn> its not like ffmpeg-mt was perfect in the first commit or anything
[14:22:59 CEST] <Compn> nor anyones' first work
[14:23:07 CEST] <nevcairiel> Compn: the point is, his patches made things much worse
[14:23:11 CEST] <nevcairiel> it was OK
[14:23:13 CEST] <nevcairiel> then it got worse
[14:24:04 CEST] <Compn> i understand
[14:24:22 CEST] <j-b> Compn: sorry, but no.
[14:24:23 CEST] <Compn> i'm not even saying it should have been committed 
[14:24:45 CEST] <j-b> Compn: I explained why those were wrong, and even _I_ could see it could not work.
[14:24:47 CEST] <Compn> i'm just addressing the attitude displayed to new developers
[14:24:57 CEST] <j-b> new developers?
[14:25:07 CEST] <nevcairiel> j-b: do you have a minute to delete the funky branch i pushed to the ffmpeg repo accidentally? its called "cf1ccfffa4b72d6dc39ea8a04bc391a4ff268fb8" ... :d
[14:25:17 CEST] <nevcairiel> Compn: he is a paid drone, but yeah
[14:25:19 CEST] <j-b> He's a paid-by-Intel developer that is stealing lu_zero's work and doing it badly.
[14:25:50 CEST] <Compn> you are saying paid drones cant/wont be contributors in the future
[14:26:08 CEST] <Compn> i have not investigated into stealing allegations, of course i dont agree with that
[14:26:21 CEST] <j-b> I'm saying merging features just to not merge libav's, because of hatred, is stupid
[14:26:32 CEST] <Compn> sure, i can agree with that
[14:26:40 CEST] <Compn> ask nevcairiel to revert and merge libavs then
[14:26:48 CEST] <nevcairiel> libavs was merged
[14:26:56 CEST] <Compn> or revert intel until its fixed
[14:26:58 CEST] <j-b> nevcairiel: there is no branch like this :)
[14:27:07 CEST] <nevcairiel> thanks j-b
[14:27:08 CEST] <j-b> nevcairiel: there was never a branch named like this :)
[14:27:18 CEST] <Compn> nevcairiel : it might be on your local checkout only..
[14:27:19 CEST] <j-b> and those droids are not the ones you are looking for.
[14:27:24 CEST] <j-b> :D
[14:27:29 CEST] <nevcairiel> Compn: he is just making jokes
[14:27:36 CEST] <j-b> ouch
[14:27:41 CEST] <Compn> ah
[14:27:43 CEST] <nevcairiel> but he did remove it
[14:27:45 CEST] <nevcairiel> so yay
[14:27:45 CEST] <j-b> I'll tag </s> and </j>
[14:27:53 CEST] <Compn> sorry , its early here
[14:28:02 CEST] <ubitux> /nick j-k
[14:28:29 CEST] <nevcairiel> i figured out how that problem happened in the first place, so i better not do that particular push mistake in the future
[14:28:59 CEST] <ubitux> so what's the story with qsv?
[14:29:17 CEST] <ubitux> ah there is a summary on the ml
[14:29:33 CEST] Action: Compn hides under his rock
[14:30:01 CEST] <nevcairiel> in short, libav decoder was merged and worked fine for h264-only at first, some paid-by-intel developer showed up and started patching the ffmpeg version, breaking half of it in the process
[14:30:35 CEST] <nevcairiel> but as long as we stop merging new features from him until its all fixed again, we can hopefully remedy it
[14:30:40 CEST] <ubitux> what did he do, or tried to do?
[14:30:50 CEST] <nevcairiel> adding more codecs
[14:30:50 CEST] <ubitux> adding more codecs?
[14:30:55 CEST] <ubitux> that's all?
[14:31:08 CEST] <nevcairiel> his code refactoring failed
[14:31:11 CEST] <nevcairiel> for now thats all
[14:31:14 CEST] <ubitux> ok
[14:31:17 CEST] <nevcairiel> i think he wants to add post-processing features
[14:31:31 CEST] <ubitux> is qsv usable on linux
[14:31:33 CEST] <ubitux> ?
[14:31:34 CEST] <Compn> i think it would be neat to have mjpeg hwaccel , but thats just me :P
[14:31:45 CEST] <nevcairiel> ubitux: yes, if you use lucas mfx library
[14:31:55 CEST] <nevcairiel> (https://github.com/lu-zero/mfx_dispatch)
[14:32:14 CEST] <ubitux> ok
[14:32:23 CEST] <nevcairiel> not sure official intel sdk has linux support yet
[14:32:25 CEST] <nevcairiel> but maybe it does
[14:32:38 CEST] Action: nevcairiel doesnt know nor care
[14:32:55 CEST] <Compn> intel should give us some chips to test these with :P
[14:33:19 CEST] <BBB> poor intel people
[14:33:21 CEST] <nevcairiel> there is even software emulation, at least on windows, you dont necessarily need hardware support
[14:33:27 CEST] <BBB> I had a chat with one of them at the webm summit
[14:33:39 CEST] <Compn> nevcairiel : well, i want to benchmark :P
[14:33:51 CEST] <[-T-]> i am using it under linux
[14:33:55 CEST] <[-T-]> it works but it's a pain to setup
[14:34:35 CEST] <ubitux> what's the reason to have that code in a lib btw? c++ only?
[14:34:49 CEST] <Compn> instead of where? kernel ?
[14:34:54 CEST] <Compn> or put in ffmpeg ?
[14:34:58 CEST] <ubitux> instead of ffmpeg obv
[14:35:08 CEST] <nevcairiel> that library is c++ yes, but its only a small dispatcher library that loads the intel binary plugins
[14:35:11 CEST] <ubitux> or libav fwiw
[14:35:16 CEST] <nevcairiel> the code is from the intel sdk
[14:35:16 CEST] <Compn> probably so other things can use it  i guess
[14:35:22 CEST] <Compn> also binary.
[14:35:22 CEST] <nevcairiel> slightly adapted for easier building
[14:35:29 CEST] <ubitux> nevcairiel: ok
[14:35:34 CEST] <nevcairiel> might be license problems to include it directly
[14:35:35 CEST] <nevcairiel> also, bloat
[14:35:36 CEST] <Compn> and so we dont have to maintain it
[14:35:36 CEST] <nevcairiel> .D
[14:35:43 CEST] <ubitux> ok
[14:35:50 CEST] <Compn> wm4 : someone is thinking about bloating ffmpeg, get out here and tell him not to! :P
[14:36:04 CEST] <ubitux> just asking to check if the sole reason would be c++ (because iirc libav doesn't allow it, while we ended up tolerating it)
[14:36:13 CEST] <nevcairiel> its quite a bit of code, too
[14:36:14 CEST] <Compn> fair enough, good question.
[14:36:31 CEST] <Compn> i think we had similar argument about vaapi or some other api 
[14:36:31 CEST] <nevcairiel> and considering its practically 1:1 from the  Intel SDK, keeping it separate is probably ok
[14:36:43 CEST] <Compn> s/api/hwaccel
[14:36:54 CEST] <nevcairiel> i think luca added the linux module in his fork there
[14:36:54 CEST] <ubitux> nevcairiel: yeah ok
[14:37:42 CEST] <nevcairiel> ok then lets test the asm thing for bbb
[14:38:04 CEST] <[-T-]> the biggest pain to me is to have to patch the i915 module
[14:38:13 CEST] <[-T-]> i had to go back to kernel 3.14 to use it
[14:38:45 CEST] <ubitux> (so nevcairiel is our new leader? @_@)
[14:38:51 CEST] <nevcairiel> nah
[14:39:02 CEST] <nevcairiel> i'm way too lazy to lead anyone
[14:40:47 CEST] <Compn> no leader, maybe we should split leader duty into different jobs
[14:41:37 CEST] <Compn> e.g. one person to resolve technical conflicts/reverts , then one person to handle policy conflicts?  i dunno
[14:42:56 CEST] <BtbN> idealy more than one person, so someone can actualy take a break without stuff falling apart
[14:44:51 CEST] <nevcairiel> I'm just trying to help out a bit, I was asked before but didn't really have the time at the time, so..
[14:46:14 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:77fb14f03903: avcodec/rawenc: Use ff_alloc_packet2()
[14:46:14 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:fdc2385ca96c: avcodec/libwebpenc_animencoder: Use ff_alloc_packet2()
[14:46:14 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:4302a9283531: avcodec/pcm: Better min_size for ff_alloc_packet2()
[14:49:06 CEST] <wm4> <Compn> wm4 : someone is thinking about bloating ffmpeg, get out here and tell him not to! :P <- I'm not sure what you're trolling about now, but this QSV disaster is a good example how adding new features breaks shit
[14:51:08 CEST] <nevcairiel> the worst part is that its just a function of impatience
[14:51:21 CEST] <nevcairiel> as libav is working on the same things
[14:51:40 CEST] <nevcairiel> (or ignorance of what happens at libav, who knows if that dev even knows they exist)
[14:52:16 CEST] <Compn> see you c ould show them libav threads
[14:52:25 CEST] <Compn> you guys know its ok to post libav urls on the ffmpeg ml right ?
[14:52:26 CEST] <Compn> :P
[14:52:47 CEST] <ubitux> if the guys doesn't react, just revert it
[14:53:02 CEST] <nevcairiel> he probably will react
[14:53:26 CEST] <Compn> and you can totally send the intel guy to libav. theres no reason to duplicate work
[14:53:34 CEST] <nevcairiel> the real question is how long until the issues are fixed in a satisfactory manner
[14:53:37 CEST] <Compn> and theres no policy banning free speech here...
[14:54:06 CEST] Action: Compn wonders if he just talks to himself
[14:54:08 CEST] Action: Compn afk bbl
[14:54:17 CEST] <Compn> thanks nevcairiel btw :)
[14:54:19 CEST] <ubitux> Compn: why are you talking about duplicated work, it's not what it's about
[14:54:28 CEST] <nevcairiel> well kind of is
[14:54:35 CEST] <Compn> some kind of duplication at least
[14:54:36 CEST] <ubitux> isn't he working on top of libav work?
[14:54:39 CEST] <nevcairiel> he duplicated a bunch of things that libav changed a week later
[14:54:40 CEST] <Compn> if they arent working together.
[14:54:54 CEST] <wm4> nevcairiel: haha
[14:55:03 CEST] <wm4> nevcairiel: so he literally copied the patches off the Libav ML?
[14:55:06 CEST] <nevcairiel> ubitux: he is working on the first version that libav produced, but libav is still continuing their work, now in parallal with the other guy
[14:55:19 CEST] <nevcairiel> wm4: they wouldnt be as broken then i would wager
[14:55:22 CEST] <wm4> or were these things that Libav changed separate git commits?
[14:55:47 CEST] <wm4> because if he copied the patches without attribution, that's a blatant copyright violation
[14:55:57 CEST] <nevcairiel> nah i think he tried to do it himself
[14:56:03 CEST] <nevcairiel> but result was pretty similar, just more broken
[14:56:59 CEST] <nevcairiel> for example, libav uses the avcodec parsers to detett changes in the bitstream, so they can re-init the decoder to handle frame size changes etc
[14:57:34 CEST] <nevcairiel> but the guys plans include more codecs than we have parsers for, so instead of building a parser (which libav would've done), he removed the avcodec parser usage and used the media sdk parser instead
[14:57:48 CEST] <nevcairiel> ... but now frame size changes are not handled at all anymore :)
[14:57:55 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:6b0fa73b4d47: avcodec/videotoolbox: Fix bistream typo
[14:57:56 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:8bdd0dbd60b0: avcodec/videotoolbox: Add missing AV_ prefix to CODEC_ID in comment
[14:58:27 CEST] <wm4> nevcairiel: wow that's bad
[14:58:45 CEST] <ubitux> michaelni: thx, sorry i didn't notice the AV_
[14:58:52 CEST] <nevcairiel> amazingly it doesnt crash when the frame size increases
[14:59:01 CEST] <nevcairiel> the intel thing must validate buffers more than i expected it to
[15:01:11 CEST] <nevcairiel> it did give me an excuse to fix my secondary box with an intel gpu in it though
[15:07:32 CEST] <ubitux> michaelni: maybe -1 could be a special case where 3rd == 4th arg? i see only two cases so far
[15:07:39 CEST] <ubitux> either 0, or 3rd arg duplicated
[15:07:48 CEST] <ubitux> (ff_alloc_packet2)
[15:07:54 CEST] <nevcairiel> magic values :(
[15:07:55 CEST] <thardin> michael resigned?
[15:08:02 CEST] <thardin> I feel like I've been living under a rock
[15:08:55 CEST] <wm4> must have been a heavy rock
[15:12:56 CEST] <michaelni> ff_alloc_packet2 is documented in internal.h, if the docs are shit, tell me and ill fix it in a few hours but please be specific on what is bad so i know what needs to be improved
[15:17:07 CEST] <wm4> libavformat/internal.h?
[15:17:16 CEST] <wm4> I don't see it there
[15:17:57 CEST] <ubitux> codec
[15:18:30 CEST] <nevcairiel> that always confuses me as well, for some reason the packet managing functions are avcodec
[15:18:36 CEST] <nevcairiel> but i always look in avformat
[15:19:05 CEST] <prelude2004c> good morning everyone
[15:19:09 CEST] <nevcairiel> but admittedly both make sense
[15:19:17 CEST] <nevcairiel> avformat creates and eats avpackets
[15:19:20 CEST] <nevcairiel> but so does avcodec
[15:19:22 CEST] <prelude2004c> i am using ffmpeg to segment out the HLS ..
[15:19:31 CEST] <prelude2004c> i am having a problem i can't seem to figure out... i have an index file ( m3u8 ) with 30 segments ( each with 3 second chunks ) .. eg.. file_0000001.ts , ..000002.ts, etc etc ..  for some reason everytime i pull up vlc and try to play the stream .. it starts up near the end or somewhere else but never at the first segment .. i don't undersatnd why
[15:20:04 CEST] <nevcairiel> its probably a live playlist, where the specification says you are supposed to start near the end to stay close to the "live" position
[15:20:17 CEST] <prelude2004c> how do i change that ? 
[15:20:21 CEST] <prelude2004c> so it alwasy uses the first file
[15:20:37 CEST] <prelude2004c> but is in a live stream
[15:20:54 CEST] <nevcairiel> you probably cant
[15:21:09 CEST] <nevcairiel> its the players choice where to start
[15:21:09 CEST] <prelude2004c> can't i set with VOD without the END ?
[15:22:01 CEST] <nevcairiel> VOD requires an endlist, or its invalid
[15:22:27 CEST] <nevcairiel> what you could use is an event playlist, but i dont know how the players react to that specifically
[15:23:59 CEST] <prelude2004c> :( 
[15:25:16 CEST] <nevcairiel> looks like any live playlist is specified for the player to resume near the end
[15:25:28 CEST] <nevcairiel> ie. any with no end tag
[15:25:54 CEST] <prelude2004c> there has to be a way to tell the players to alwasy start at the top
[15:26:17 CEST] <prelude2004c> because that is silly.. i am doing some long distance transfring and on purpose i setup a queue of like 30 files to make sure the playback stays well ahead of the upload
[15:26:27 CEST] <prelude2004c> if it starts near realtime .. doens't help me very much :(
[15:26:35 CEST] <nevcairiel> thats not what hls is for, i guess
[15:26:41 CEST] <prelude2004c> i don't mind the 2 - 3 min delay
[15:27:05 CEST] <prelude2004c> any recommendations on how i could take a stream and segment via fiels to play on the other end
[15:27:23 CEST] <prelude2004c> the internet is slow .. i mean i can transfer 10 files at once at 100Kbit/s each .. but i can't transfer 1 file at 1Mbit/s each
[15:27:35 CEST] <wm4> michaelni: I have no idea what the min_size parameter does
[15:27:38 CEST] <prelude2004c> so it queues and i send them all one by one for example.. and within 10 seconds all files show up at once
[15:28:05 CEST] <BtbN> what kind of broken connection is that?
[15:29:37 CEST] <prelude2004c> its silly from canada / china
[15:29:38 CEST] <kierank> Compn: no offence but you are just confusing this guy about pcm_s24le
[15:29:43 CEST] <kierank> it's clearly integer
[15:29:46 CEST] <prelude2004c> the latency causes slow upload
[15:29:56 CEST] <prelude2004c> but i can do multiple simultaniously
[15:30:29 CEST] <prelude2004c> hey what is the difference between segment_list_flags +live and segment_list_flags live
[15:31:21 CEST] <prelude2004c> maybe there is some way for me to select vod without an endlist 
[15:33:19 CEST] <nevcairiel> that would be an invalid list, and may not change the behavior of players
[15:33:36 CEST] <nevcairiel> for example, ffmpegs logic is simple, if the list is not finished, it'll pick one close to the end
[15:33:39 CEST] <nevcairiel> no matter if vod or not
[15:33:55 CEST] <BtbN> so.. just use udp streaming and the latency shouldn't matter? Might run into massive packet loss then though
[15:33:58 CEST] <nevcairiel> which makes perfect sense, since vod lists are supposed to be finished
[15:36:01 CEST] <prelude2004c> ya can't use UDP . huge packet loss
[15:36:23 CEST] <BtbN> well, you can't realy get a stable stream in that situation
[15:36:27 CEST] <prelude2004c> the only solution to my problem is to buffer the data there in terms of files. and for each segment send the file ( eg. 3 second files ) to the destination one by one
[15:36:34 CEST] <BtbN> something like rtmp might work best
[15:36:35 CEST] <prelude2004c> and send them all at the same time if we have to
[15:36:47 CEST] <prelude2004c> rtmp wouldn't work iether i don't think
[15:36:53 CEST] <prelude2004c> not with packet loss
[15:37:12 CEST] <BtbN> you just want to transmit a video file, or what are you trying to do? Or a live stream?
[15:37:50 CEST] <prelude2004c> i like the logic of... queue 30 files... send one and if its not finished its ok send the other.. and then there may be 10 files uploading at a time.. thats ok because as long as the customer never catches up to the realtime files they will never reach the end where there is a problem
[15:37:56 CEST] <prelude2004c> live stream
[15:38:02 CEST] <prelude2004c> vod would be easy
[15:38:06 CEST] <prelude2004c> but what i need to do is a live stream
[15:38:45 CEST] <BtbN> none of the protocols in existance would handle that situation
[15:38:59 CEST] <prelude2004c> yup i know.. so that is why i am tryign to do it differnetly :) 
[15:39:11 CEST] <prelude2004c> so really i may have to adjust a player and customize it ?
[15:39:16 CEST] <prelude2004c> like an open source player or something
[15:39:45 CEST] <nevcairiel> ffmpegs hls demuxer has an option that lets you specify from which segment to start
[15:39:55 CEST] <nevcairiel> but you still need a player to use that option
[15:40:10 CEST] <prelude2004c> really what option is that ? vlc doesn't support ?
[15:40:17 CEST] <BtbN> that won't make it load multiple segments in parallel
[15:40:31 CEST] <prelude2004c> i have the option of " start_number 1 " set but didn't do anything
[15:40:38 CEST] <nevcairiel> ie. ffmpeg -live_start_index 0 -i hlsurl ....
[15:40:50 CEST] <nevcairiel> or 1, or whatever index it starts with
[15:41:00 CEST] <prelude2004c> ahh you mean for playback
[15:41:08 CEST] <nevcairiel> of course
[15:41:18 CEST] <prelude2004c> ya wont help me though.
[15:41:29 CEST] <prelude2004c> the player isn't the problem.. its getting files to the other end on time
[15:41:46 CEST] <BtbN> well, the only propper solution for that is fixing your connection.
[15:41:51 CEST] <prelude2004c> i have to adjust a player that will play HLS from the beginning if m3u8 ( alwasy beginning of stream ) 
[15:42:03 CEST] <prelude2004c> can't fix connection
[15:42:06 CEST] <BtbN> If you have 50% package loss and multi-second latency, no magic can safe you
[15:42:24 CEST] <prelude2004c> latency is 300ms and packet loss is like 20 %
[15:42:33 CEST] <BtbN> Use mpeg-ts with strong fec and send it via udp.
[15:42:38 CEST] <prelude2004c> but.. i have found that i run parallel uploads and eventually they all show up
[15:42:48 CEST] <prelude2004c> if hte queue is large enough, it never shows up 
[15:42:55 CEST] <prelude2004c> eg.. it takes 10 seconds to upload a 3 second file
[15:43:03 CEST] <prelude2004c> if you upload 5 files at once.. it never catches up
[15:43:30 CEST] <BtbN> I'm not sure if ffmpeg is able to insert fec data for mpegts though
[15:43:46 CEST] <nevcairiel> dont think so
[15:44:02 CEST] <kierank> no it can't
[15:44:07 CEST] <prelude2004c> you gav eme an idea... what about on the other end.. ffmpeg -i start at index 0  and output to rtmp or something
[15:44:10 CEST] <prelude2004c> so the players can use rtmp
[15:44:15 CEST] <prelude2004c> its not adaptive but...
[15:44:27 CEST] <kierank> and the only standardised fec supports ~20%ish packet loss
[15:44:28 CEST] <prelude2004c> at least i can force it locally to be from beginning
[15:44:38 CEST] <kierank> you'd have to essentially roll your own if you want more
[15:44:43 CEST] <nevcairiel> ffmpeg probably cant even read fec data
[15:48:51 CEST] <ubitux> i'm planing to add a lock/condition pthread mechanism in VTB private context to control async mode; not familiar with either apple framework and the ffmpeg accels, does it make sense to do it that way?
[15:49:36 CEST] <nevcairiel> dont think any ffmpeg hwaccel has any precendence for that
[15:50:38 CEST] <wm4> qsv and mmal connect async decoders with the sync ffmpeg api
[15:50:50 CEST] <wm4> (not sure about qsv?)
[15:50:53 CEST] <nevcairiel> yeah but not with any thread functions
[15:50:59 CEST] <ubitux> i didn't see any cb mechanism in qsv, but i looked very quickly
[15:51:03 CEST] <nevcairiel> the API does the syncing without needing threads
[15:51:12 CEST] <nevcairiel> (ie. it does threads internally)
[15:51:13 CEST] <wm4> it's mostly a data flow issue IMO?
[15:51:45 CEST] <BtbN> The nvenc async api uses WinAPI, so i didn't even bother dealing with it.
[15:52:15 CEST] <nevcairiel> nvenc is still plenty fast
[15:52:21 CEST] <BtbN> it is now
[15:52:51 CEST] <nevcairiel> i wonder if these dataflow hacks could also help ubitux's performance woes
[15:52:55 CEST] <nevcairiel> or if async is the only answer
[15:53:07 CEST] <BtbN> i guess it does the async stuff internaly now
[15:53:09 CEST] <nevcairiel> depends how the driver acts i guess
[15:53:24 CEST] <BtbN> copying the buffers internaly to system ram when the bandwidth is free
[15:53:26 CEST] <BtbN> or something like that
[15:53:29 CEST] <prelude2004c> so i am going to try something.. i have the files on the remote side but the problem is the player ... so.. going to try the ffmpeg -live_start_index 0 -i http://localhost/...m3u8 and then -f flv to a local port where people can stream from
[15:53:31 CEST] <prelude2004c> that may work
[15:53:36 CEST] <nevcairiel> nvidia is pretty good with copying to sysram anyway
[15:53:46 CEST] <nevcairiel> they actually use DMA for that so you dont have to use secret sauce to make it fast
[15:53:51 CEST] <prelude2004c> can someone tell me what the best output should be ?
[15:54:00 CEST] <BtbN> there are various modes in which the buffers can be mapped
[15:54:01 CEST] <nevcairiel> intel and amd .. you better have sse4 copy functions handy, or its going to be slow 
[15:54:10 CEST] <BtbN> SYSTEM_CACHED was the fastest in my tests
[15:54:47 CEST] <nevcairiel> even talking generic like in dxva2, when i map a dxva surface for reading, its already in system memory with nvidia, so any plain memcpy is fast
[15:54:59 CEST] <nevcairiel> with intel or amd, you directly map the gpu memory
[15:55:04 CEST] <nevcairiel> so you have to be careful to access it fast
[15:55:13 CEST] <BtbN> it's not even gpu memory in case of intel
[15:55:22 CEST] <nevcairiel> well its still slow withotu sse4 things
[15:55:34 CEST] <BtbN> yeah, because they use some weird memory type
[15:55:41 CEST] <BtbN> but it's in the system memory portion
[15:55:45 CEST] <cone-236> ffmpeg 03Hendrik Leppkes 07master:5d324dae114e: dxva2_hevc: properly signal the num_delta_pocs from the SPS RPS
[15:56:45 CEST] <nevcairiel> anyway, the point was, nvidia is nice to you and DMA's it into system memory when you arent looking
[15:56:50 CEST] <nevcairiel> which is plenty fast
[15:57:17 CEST] <BtbN> unless you force it to happen imediately aparently
[15:57:26 CEST] <nevcairiel> the only downside, they reserve a DMA buffer in frame size for every surface you use
[15:57:30 CEST] <nevcairiel> which can eat memory
[15:57:41 CEST] <nevcairiel> especially when handling 4k 10bit in a 32-bit process
[15:58:12 CEST] <nevcairiel> BtbN: i guess forcing a sync will break every advantage at some point :D
[15:58:26 CEST] <BtbN> 4k would result in 32 buffers beeing used
[15:58:34 CEST] <BtbN> that's quite a bit of address space
[15:58:35 CEST] <wm4> if I copy back to RAM with system memcpy on vaapi/intel, it usually seems to be ok
[15:58:42 CEST] <nevcairiel> why 32 buffers
[15:58:49 CEST] <BtbN> because the doc says so
[15:59:00 CEST] <nevcairiel> for encoding?
[15:59:17 CEST] <nevcairiel> but yeah thats a lot of buffers
[15:59:18 CEST] <BtbN> yeah, they basicaly told you how to calculate the buffer count, i just used the exact forumla
[16:00:04 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc.c;hb=HEAD#l693
[16:00:05 CEST] <nevcairiel> wm4: dont know about vaapi, but with dxva2 its butt-slow on intel without the special sse4 instructions
[16:00:44 CEST] <nevcairiel> oh its just a small limiter to not exceed memory constraints i guess
[16:03:07 CEST] <BtbN> i actualy reduced the count for the later case
[16:03:19 CEST] <BtbN> it was 96 in their example
[16:03:35 CEST] <BtbN> setting it to a fixed 32 would propably work fine, too
[16:03:39 CEST] <nevcairiel> i guess thats the number of frames it can use for look-ahead to some degree?
[16:04:03 CEST] <BtbN> it handles keeping frames for look-ahead internaly
[16:04:11 CEST] <BtbN> you don't need to bother with that
[16:04:33 CEST] <nevcairiel> then its just for parallel encoding?
[16:04:34 CEST] <prelude2004c> hey should i use for streaming udp:// or rtmp:// 
[16:04:40 CEST] <prelude2004c> which is going to be better for a customer playback
[16:04:48 CEST] <BtbN> for parallel copying back to sysmem i'd guess
[16:04:53 CEST] <nevcairiel> or that
[16:05:10 CEST] <BtbN> it propably collects a few frames, and then does one big dma copy, or something like that
[16:05:16 CEST] <prelude2004c> or rtp?
[16:06:12 CEST] <nevcairiel> if its a singlecast operation (ie 1 user), something using tcp is probably better, but if multiple users are supposed to receive it, low-overhead UDP may have advantages
[16:06:51 CEST] <prelude2004c> hum..
[16:07:04 CEST] <prelude2004c> what do you think is the best way for me to do it.. eg
[16:07:33 CEST] <prelude2004c> ffmpeg -live_start_index 0 -i http://localhost:8080/channels/source/source.m3u8 -codec copy -f < some local port > 
[16:07:45 CEST] <prelude2004c> if i can't use m3u8 for playback then i would like to use something else
[16:07:50 CEST] <prelude2004c> if ffmpeg can play from beginning its perfect
[16:08:08 CEST] <prelude2004c> ffmpeg will do the playback and send it to some other process that the actual vlc will play or stb will play from customer location
[16:08:30 CEST] <prelude2004c> i just have to decide on the best output approach
[16:08:39 CEST] <prelude2004c> rtmp/ rtp / udp/ etc
[16:08:44 CEST] <prelude2004c> not sure which would work the best
[16:09:49 CEST] <BtbN> Why exactly are you talking about this in #ffmpeg-devel?
[16:10:36 CEST] <prelude2004c> sorry guys.. because i don't know if the ffmpeg guys would know this :( 
[16:10:43 CEST] <prelude2004c> but its ok i can move there and try
[16:12:19 CEST] <BtbN> It's mostly the same people over there, this channel exists to keep user support and ffmpeg development separated.
[16:14:23 CEST] <wm4> and the ones only on this channel don't want to deal with user questions
[16:16:54 CEST] <ubitux> lol he's still submitting mjpeg stuff
[16:19:00 CEST] <prelude2004c> they BtbN you said -live_start_index 0 but doesnt' work  .. still starts near the bottom
[16:28:37 CEST] <nevcairiel> his quoting style annoys me too, because whatever mail app he uses puts the posters initials there, my mail thing doesnt detect it as quotes and its not displayed properly :(
[16:30:22 CEST] <wm4> mine does, amazingly
[16:30:49 CEST] <wm4> there are so many ways to quote in email...
[16:31:07 CEST] <nevcairiel> surprisingly most tools just use a single >
[16:31:26 CEST] <wm4> can't have a single style... too simple
[16:31:46 CEST] <nevcairiel> sadly mail headers dont seem to tell me what tool he uses
[16:52:06 CEST] <kierank> nevcairiel: his response is hillarious
[16:53:01 CEST] <JEEB> lol
[16:53:10 CEST] <JEEB> they are all known and in my TODO list :V
[16:53:33 CEST] <kierank> BBB: are your vp9 conference slides published anywhere
[16:54:09 CEST] <nevcairiel> why does ffmpeg over stdin not work on windows, or am i just too dumb to pipe a ts file in there
[16:54:29 CEST] <BBB> kierank: I intend to publish a blog post about it soon'ish
[16:54:34 CEST] <BBB> but havent gotten to that yet
[16:54:43 CEST] <ubitux> nevcairiel: seeking?
[16:54:52 CEST] <nevcairiel> ts shouldnt need seeking
[16:55:40 CEST] <nevcairiel> it works a bit, it outputs like one frame
[16:55:43 CEST] <nevcairiel> then claims its done
[16:55:47 CEST] <nevcairiel> but the file is 4 minutes long
[16:55:59 CEST] <Daemon404> ship it
[16:58:44 CEST] <Daemon404> "In general all these issues are known and in my todo list.
[16:58:45 CEST] <Daemon404> "
[16:58:46 CEST] <Daemon404> wat
[17:01:18 CEST] <ubitux> Daemon404: "trust me i'm an engineer"
[17:01:24 CEST] <ubitux> "i'm pissing in your mouth, no worry"
[17:02:00 CEST] <Daemon404> ubitux, are you referring to the engineer song?
[17:02:23 CEST] <ubitux> not really, it's just the expression of my huge creativity
[17:03:12 CEST] <Daemon404> https://www.youtube.com/watch?v=rp8hvyjZWHs
[17:03:56 CEST] <ubitux> didn't know from where the trust me engineer thing was coming from
[17:13:50 CEST] <kierank> no it's from dilbert
[17:17:59 CEST] <J_Darnley> nevcairiel: does something change stdin/stdout to be "text format"?
[17:19:00 CEST] <nevcairiel> they both start out as text format unless someone sets them to binary
[17:19:37 CEST] <nevcairiel> but i would think someone would've noticed that long ago in ffmpeg if that wasnt done
[17:19:40 CEST] <nevcairiel> wouldnt they...
[17:20:02 CEST] <J_Darnley> I would have thought so.
[17:21:02 CEST] <nevcairiel> the pipe protocol does call the thing to set it to binary
[17:22:04 CEST] <J_Darnley> I don't know what to say then.
[17:32:56 CEST] <wm4> what happens if someone writes W text to a binary pipe?
[17:34:00 CEST] <nevcairiel> it comes out the receiving end just like it went in?
[17:42:20 CEST] <wm4> as utf-16 or what?
[17:42:45 CEST] <nevcairiel> its binary, so however it was written n the input
[17:42:52 CEST] <nevcairiel> +o
[17:43:07 CEST] <nevcairiel> from a windows app, utf16, on linux probably utf32
[17:43:21 CEST] <wm4> I'm asking because windows has separate W APIs
[17:43:45 CEST] <wm4> and it's not really clear what would happen if you write text with a W API to a binary pipe, and read them as bytes
[19:19:15 CEST] <wm4> haha, gstreamer failed on an obscure ffmpeg API requirement
[19:19:27 CEST] <nevcairiel> not using stack avframes isnt that obscure
[19:19:37 CEST] <wm4> this one http://cgit.freedesktop.org/gstreamer/gst-libav/commit/?id=30a4a28793f2e0ff08aaea368b7c14317ac2ca21
[19:19:41 CEST] <wm4> input padding
[19:19:58 CEST] <nevcairiel> the crash quoted in that ticket shows a stack avframe
[19:20:04 CEST] <nevcairiel> which is more likely to cause breakage =p
[19:20:45 CEST] <wm4> yeah, I'm not sure how this commit is related to the ticket
[19:21:06 CEST] <nevcairiel> gst is full of bad api use
[19:21:15 CEST] <nevcairiel> although it seems to have been corrected recently
[19:21:15 CEST] <wm4> (but I didn't look too hard)
[19:21:27 CEST] <nevcairiel> of course this is linux
[19:21:32 CEST] <nevcairiel> it takes years for fixes to spread to users
[19:21:51 CEST] <wm4> that's not fair... the oldest outdated ffmpeg builds are windows builds
[19:21:57 CEST] <wm4> or was that OSX
[19:22:16 CEST] <nevcairiel> well with windows its just up to the app you use, so you can just blame the app developers
[19:22:28 CEST] <nevcairiel> but the app developer is in full control at all times
[19:22:42 CEST] <wm4> except when he needs to support XP
[19:22:51 CEST] <nevcairiel> git master still works on xp
[19:22:51 CEST] <nevcairiel> :D
[19:24:35 CEST] <nevcairiel> but say gst has a new major version out, and all these ff fixes are only in that, then an existing linux install will take ages to get these fixes, because they tend to only spread minor upgrades to existing installs
[19:25:06 CEST] <nevcairiel> although that particular ticket seems to be from someone on gentoo, that should be easier for him then
[19:44:00 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:2ca0ed9cfda2: doc/git-howto: Replace "git push" example by one with dry-run
[20:08:48 CEST] <llogan> so, did i miss anything when i left town for a few days?
[20:27:27 CEST] <philipl> llogan: tell me about it.
[20:28:19 CEST] <nevcairiel> that'll teach you do take days of, in the summer of all times
[20:28:56 CEST] <philipl> A grave mistake to make.
[20:29:32 CEST] <philipl> So is our official position that we're going to keep going, and that an un-fork is something we'd like but not required for a sustainable future?
[20:29:56 CEST] <philipl> I support that but some of the conversations sounded like an un-fork was required to have a future.
[20:30:44 CEST] <nevcairiel> some people seem to panic a bit, but if we dont even try to go on, we'll certainly  have no future
[20:33:23 CEST] <llogan> We have chance to survive make our time.
[20:33:40 CEST] <philipl> nevcairiel: agreed.
[20:34:09 CEST] <philipl> latest nvidia driver releases finally enables all the missing h264 profiles (but not 444 yet)
[20:34:45 CEST] <nevcairiel> i find it fascinating that they can encode more profiles than they can decode now :D
[20:35:15 CEST] <philipl> I was told that 444 decode was an intern project that, surprise, didn't reach a shippable state but somehow made it into the release notes for some driver.
[20:35:32 CEST] <philipl> But the hardware is capable
[20:36:05 CEST] <wm4> did they fix hevc decode yet?
[20:36:05 CEST] <nevcairiel> i dont know enough about h264 to know if there is actually different capabilities required for higher chroma profiles, or if its just more chroma data but otherwise just the same
[20:36:30 CEST] <philipl> wm4: I don't think so. José apparently committed the change just past the window for this release.
[20:37:33 CEST] <philipl> nevcairiel: the high chroma modes are profiles in and of themselves
[20:38:20 CEST] <Gramner> chroma in 4:4:4 is basically treated more like luma instead of chroma in 4:2:0/4:2:2
[20:38:20 CEST] <philipl> If we're still talking nvidia, I don't think their hardware supports > 8bit for any h264 - even the 444 profile is 8bit only
[20:38:59 CEST] <nevcairiel> yeah high bit depth is another thing entirely
[20:39:05 CEST] <philipl> I did learn they have hardware support for 10 -> 8 at the end of the decode path for hevc 10bit
[20:39:34 CEST] <nevcairiel> i never tried to do that, as i refuse to commit such crimes
[20:39:56 CEST] <nevcairiel> but it can give me full 10-bit out as well, so i also was never tempted to try
[20:39:58 CEST] <wm4> philipl: urgh why
[20:40:09 CEST] <wm4> philipl: so we get some sort of shitty hardware dithering?
[20:40:25 CEST] <nevcairiel> dxva can give you 10-bit surfaces, vdpau not have that?
[20:41:06 CEST] <nevcairiel> i never tried what happens when i use 8-bit surfaces and a 10-bit bitstream
[20:41:35 CEST] <philipl> vdpau has no 10bit support so without the conversion it would require API changes
[20:41:41 CEST] <wm4> vdpau does have API support for high bit depth surfaces, I think
[20:41:47 CEST] <philipl> which should happen eventually
[20:41:55 CEST] <philipl> wm4: It has support for output surfaces but not video surfaces
[20:41:58 CEST] <wm4> hm, or maybe not
[20:42:53 CEST] <wm4> the "HIGH_DEPTH" flag in ffmpeg's vdpau API means support for non-4:2:0 subsampling
[20:42:58 CEST] <philipl> So the quickest way to expose MAIN_10 is to use the dithering
[20:43:12 CEST] <nevcairiel> did you check by any chance if they actually dither?
[20:43:20 CEST] <nevcairiel> and not just round?
[20:43:56 CEST] <philipl> nevcairiel: I didn't. I could ask
[20:45:57 CEST] <wm4> some form if simple dithering seems likely
[20:59:25 CEST] <thardin> what fresh hell is j2ki/mxf
[21:00:22 CEST] <Daemon404> i = interlaced?
[21:00:46 CEST] <thardin> yes
[21:01:00 CEST] <thardin> seems it's each field stored as a separate j2k blob
[21:02:04 CEST] <nevcairiel> Evil
[21:02:37 CEST] <Daemon404> like hevc, kinda?
[21:02:39 CEST] <Daemon404> each field is a pic
[21:03:00 CEST] <thardin> yeah
[21:03:06 CEST] <thardin> nevcairiel: it gets worse
[21:03:15 CEST] <thardin> SeparateLines is a thing in MXF
[21:03:38 CEST] <wm4> MXF - supports everything, except nothing works
[21:03:43 CEST] <thardin> or rather, LineWrapping (compare: ClipWrapping, FrameWrapping)
[21:04:11 CEST] <thardin> MXF - creates consulting hours
[21:04:38 CEST] <JEEB> oh yes
[21:51:18 CEST] <philipl> Anyone else get 'bitcodin' spam?
[21:51:40 CEST] <JEEB> it seems to have been pushed around
[21:51:47 CEST] <kierank> spam about what
[21:51:59 CEST] <JEEB> "Maybe you are interested in testing our encoding service www.bitcodin.com, which encodes video 100x faster than realtime,..."
[21:52:02 CEST] <philipl> That one.
[21:52:58 CEST] <kierank> because you are on the ffmpeg-ml?
[21:53:13 CEST] <philipl> The email claimed it came from github trawling.
[21:53:28 CEST] Action: kierank might troll them on twitter
[22:00:04 CEST] <philipl> kierank: ask them if just use nvenc on ec2 gpu instances...
[22:00:19 CEST] <kierank> probably a slice and dice
[22:00:21 CEST] <kierank> or that
[22:01:30 CEST] <kierank> https://twitter.com/obencoder/status/628294591129759744
[22:01:31 CEST] <kierank> flame on
[22:02:09 CEST] <philipl> hehe.
[22:07:01 CEST] <wm4> ff_alloc_packet2 is my new favorite function
[22:11:41 CEST] <nevcairiel> I think i got similar spam from some company because i forked googles ExoPlayer repository, trying to sell me some other DASH solutions
[22:11:52 CEST] <nevcairiel> i wouldnt know how they otherwise figured out that I use ExoPlayer
[22:12:27 CEST] <cone-236> ffmpeg 03James Almer 07master:5750d6c5e9d1: x86: move XOP emulation code back to x86inc
[22:12:41 CEST] <nevcairiel> oh
[22:12:42 CEST] <nevcairiel> same company
[22:12:44 CEST] <nevcairiel> figures
[22:12:57 CEST] <JEEB> :D
[22:13:11 CEST] <J_Darnley> Well, now I'm just sad that nobody has spammed me yet.
[22:13:19 CEST] <rcombs> "you just found a working free solution? Consider paying us!"
[22:13:34 CEST] <J_Darnley> Should I get a Github account to receive some?
[22:14:40 CEST] <Shiz> bitcodin is only one letter away from bitcoin
[22:16:18 CEST] <thardin> I see I'm not the only one who got that spam
[22:16:30 CEST] <Daemon404> i got that too
[22:16:37 CEST] <nevcairiel> ididnt get their newest one
[22:16:41 CEST] <nevcairiel> despite having a ffmpeg repo
[22:16:53 CEST] <nevcairiel> but like i said, i got something about DASH a couple days ago
[22:17:23 CEST] <thardin> I had in mind to send something like "why, I'd be deliighted to recommended a company that sends unsolicited e-mail to people"
[22:17:28 CEST] <Daemon404> their claims are pretty lulz
[22:17:40 CEST] <kierank> I didn't get any spam
[22:17:47 CEST] <Daemon404> "Video encoding 100x faster than any other encoding service"
[22:17:55 CEST] <Daemon404> not 100x realtime
[22:17:57 CEST] <Daemon404> 100x ANY service
[22:17:58 CEST] <Daemon404> :D
[22:18:05 CEST] <JEEB> yup
[22:18:41 CEST] <thardin> sometimes I wonder how many bogus companies like that there are
[22:18:46 CEST] <nevcairiel> with segmenting its probably possible to do that
[22:18:48 CEST] <nevcairiel> but i doubt they do
[22:19:00 CEST] <thardin> why would you need that?
[22:19:20 CEST] <thardin> like, if you have lots to encode you can just encode each file offline on separate processes
[22:19:41 CEST] <thardin> if realtime then 1x realtime etc
[22:19:49 CEST] <thardin> (with room to spare ofc)
[22:20:51 CEST] <Daemon404> nevcairiel, possible to do whta?
[22:20:55 CEST] <Daemon404> any service can do it
[22:21:00 CEST] <Daemon404> you cant encode 100x faster than any service
[22:21:01 CEST] <Daemon404> ;)
[22:21:11 CEST] <nevcairiel> if noone else does it, then its still true
[22:21:16 CEST] <nevcairiel> :D
[22:21:24 CEST] <Daemon404> and that's already untrue
[22:21:40 CEST] <philipl> My email says 100x realtime
[22:22:17 CEST] <Daemon404> philipl, their siet says 100x any service
[22:22:20 CEST] <Daemon404> site*
[22:22:25 CEST] <philipl> hah.
[22:22:30 CEST] <BBB> oh yeah I got that email also
[22:22:39 CEST] <BBB> its not hard to make something thats 100x faster than anything
[22:22:40 CEST] <nevcairiel> so by reflection, any other service only offers realtime? :)
[22:22:58 CEST] <BBB> just write a static sps/pps/vps and a static image of size NxN that has no coefficients and does dc prediction
[22:23:00 CEST] <BBB> entirely grayscale
[22:23:02 CEST] <BBB> superfast
[22:23:17 CEST] <BBB> and whenever people complain about quality, just say psnr sucks
[22:23:24 CEST] <BBB> easy peasy
[22:23:55 CEST] <philipl> https://aws.amazon.com/blogs/aws/build-3d-streaming-applications-with-ec2s-new-g2-instance-type/
[22:24:00 CEST] <philipl> I too can start such a service.
[22:24:57 CEST] <kierank> 3d
[22:24:58 CEST] <kierank> lol
[22:28:15 CEST] <Gramner> just write some H.264 headers and output raw yuv as PCM blocks. from and to a RAM-disk. it's really fast AND the psnr is excellent.
[22:28:26 CEST] <nevcairiel> lol
[22:31:41 CEST] <JEEB> :D
[23:39:48 CEST] <philipl> sweet. latest nvidia driver fixes the hevc bug. they updated the release notes
[23:52:53 CEST] <wm4> philipl: I wonder what we do about the code disabling it in ffmpeg
[23:52:56 CEST] <wm4> maybe just drop it
[23:53:29 CEST] <wm4> unless there's the possibility that the broken drivers will be around for a longer time for some reason
[00:00:00 CEST] --- Tue Aug  4 2015