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

[burek]

[00:03:10 CEST] <cone-142> ffmpeg 03Josh de Kock 07master:6bb99757b780: jack: Support OSX
[00:03:11 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:dc0152548f03: Merge commit '6bb99757b780144d9fa27cdce09d3621e1a0ed43'
[00:08:09 CEST] <cone-142> ffmpeg 03Luca Barbato 07master:1db8eb154908: avconv: Drop an unused variable
[00:08:10 CEST] <cone-142> ffmpeg 03Tim Walker 07master:fef2147b7a68: eac3dec: don't call avpriv_request_sample every frame.
[00:08:11 CEST] <cone-142> ffmpeg 03Tim Walker 07master:33275a0de05e: ac3dec: change logging of skipped E-AC-3 substreams.
[00:08:12 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:b3051a460cf0: vaapi_h264: Fix bit offset of slice data.
[00:08:13 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:9109b5240b5e: Merge commit '1db8eb154908cde577477b6ab17430a0cd46b7bd'
[00:08:14 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:15cb52577a84: Merge commit 'fef2147b7a689b80d716c3edb9d4a18904865275'
[00:08:15 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:13b77e09c7e9: Merge commit '33275a0de05e9bc321f2537a2a67921fab81624f'
[00:08:16 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:2d2af18f42c9: Merge commit 'b3051a460cf02a5b86ff0d1e14abba23ea55ff6d'
[00:26:43 CEST] <cone-142> ffmpeg 03Luca Barbato 07master:e3453fd44480: matroska: Write the field order information
[00:26:44 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:ee865e9780b4: Merge commit 'e3453fd44480d903338c663238bf280215dd9a07'
[00:27:56 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:4c6836db0f30: nvenc_h264: Fix name of private AVClass
[00:27:57 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:f0d4f3026d0f: Merge commit '4c6836db0f300d2c0401c6a1927a95c3258cc1ae'
[00:28:45 CEST] <Daemon404> q
[00:33:25 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:51dc4de1218a: rscc: Add extended pixel format support
[00:33:27 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:dd2d26dc82b8: Merge commit '51dc4de1218a81ee8e5b3f941839c5e3125a6d4b'
[00:34:21 CEST] <jamrial> i thought the matroska spec allowed elements to be ignored if they are not recognized?
[00:34:36 CEST] <jamrial> as in, non webm elements in a webm file shouldn't make it unreadable
[00:34:48 CEST] <Daemon404> sure but we shouldnt write it anyway
[00:34:57 CEST] <Daemon404> if it is technically wrong
[00:35:23 CEST] <jamrial> yeah, that's true
[00:42:46 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:b5f47d95c6cb: fate: Update RSCC tests
[00:42:47 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:e4c8e1906440: Merge commit 'b5f47d95c6cb8ffa9982eb8fd3e9ab5c9f97e914'
[00:43:04 CEST] <Daemon404> i already synced samples to our fate suite ^
[00:47:29 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:95db8c757cb0: screenpresso: Add extended pixel format support
[00:47:30 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:ec8a69fab657: screenpresso: Correctly handle keyframes
[00:47:31 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:8dde92b95a19: fate: Update Screenpresso tests
[00:47:32 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:5d31074daf0e: Merge commit '95db8c757cb003a71b040b567f38be74151deb5c'
[00:47:33 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:483e9d8a2bb4: Merge commit 'ec8a69fab657f9cce624e8b0f4069d12696890bf'
[00:47:34 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:486776d06f6e: Merge commit '8dde92b95a197eb809d798aacb34dbe52a0689a8'
[00:55:52 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:9a9fb710bcf4: dds: Add support for rgb555 files
[00:55:53 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:02538636261f: dds: Add support for alpha-only files
[00:55:54 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:22e49e6edead: dds: Simplify postprocessing check
[00:55:55 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:00658253e237: fate: Update DDS tests
[00:55:56 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:6c007036850c: Merge commit '9a9fb710bcf4657e030467cfe2556cb0e2c01afc'
[00:55:57 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:6ebec1049ea6: Merge commit '02538636261fdec9c70f4185b23147c636f269b4'
[00:55:58 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:d62984d8a081: Merge commit '22e49e6edead9c83696f20127988f659b952ce65'
[00:55:59 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:68b8505d4d3f: Merge commit '00658253e237ab975ae2d384e02b5936781f103d'
[00:58:12 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:e656a6ccd9ca: configure: cosmetics: Drop pointless end-of-line semicolons
[00:58:13 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:38eeb85ff344: Merge commit 'e656a6ccd9cab1b0a79cffe3e609793857aae330'
[00:58:55 CEST] <Daemon404> thats enough for todya.
[03:29:56 CEST] <Compn> http://www.sciencemag.org/news/2016/04/whos-downloading-pirated-papers-everyone
[03:30:59 CEST] <Compn> That has forced the site to move to sci-hub.bz and sci-hub.cc.
[03:31:03 CEST] <Compn> ah thats where it went...
[08:34:43 CEST] <rcombs> anyone know why nv12 is explicitly excluded from drawutils support?
[08:34:58 CEST] <rcombs> afaict it works fine, at least for vf_subtitles
[08:35:59 CEST] <rcombs> oh, wait, it does fuck up the chroma
[08:36:04 CEST] <rcombs> alright, I'll fix that
[09:10:22 CEST] <durandal_1707> why hwdownload and hwupload filters are not documented?
[09:44:52 CEST] <j-b> 'morning
[10:36:54 CEST] <yann> looks like dca23ff and f3aff31 introduce an API change, which is not documented in APIchanges, right?
[10:41:06 CEST] <nevcairiel> its not exactly an api change, just deprecation of existing API, and the replacements existed for a l ong time before that already, but it wouldnt do any harm to list it in api changes
[10:43:48 CEST] <yann> at least it's surprising, when upgrading to 3.0, to get deprecatation warnings and having to git blame to get the info :)
[10:47:43 CEST] <wm4> yann: is it not in apichanges.txt?
[10:47:51 CEST] <wm4> well, doc/APIchanges
[10:48:13 CEST] <yann> did not find it, and the commits listed above do not touch this file
[10:49:02 CEST] <wm4> right, AVPicture itself seems to be missing from that file
[10:49:07 CEST] <wm4> it shouldn't
[10:49:08 CEST] <nevcairiel> avpicture* didnt seem to  occur much in the file
[10:56:29 CEST] <yann> I'm also wondering, since I am using AVPicture precisely because we can cast an AVFrame to it, if the change is really beneficial - I am conditionally doing colorspace conversion after decoding, and I'm using the AVFrame-castability-to-AVPicture so the next steps don"t have to bother what they got - with imgutils it seems to me I basically have to create my AVPicture equivalent, I'm not sure it really makes sense :)
[10:58:58 CEST] <nevcairiel> you can just pass the elements of an AVFrame directly to av_image_* functions, no need to have an intermediate struct
[11:00:31 CEST] <yann> yes, 2 related arrays instead of a neat struct binding them together :)
[11:01:31 CEST] <fritsch> yann: see the kodi transition from AVPicture to AVFrame we used the same av_image methods were needed
[11:01:43 CEST] <fritsch> if you are interested
[11:02:42 CEST] <fritsch> https://github.com/xbmc/xbmc/commits/master/xbmc/guilib/FFmpegImage.cpp
[11:03:32 CEST] <fritsch> if you find bugs, happy to fix them
[11:04:59 CEST] <yann> yes, using a full AVFrame is an option, but that's arguably a heavyweight struct just for 2 pointers :)
[11:06:40 CEST] <wm4> " and I'm using the AVFrame-castability-to-AVPicture "
[11:06:52 CEST] <fritsch> i hope you cast the other way round
[11:06:56 CEST] <fritsch> :-)
[11:06:58 CEST] <wm4> that's exactly why we deprecated it (or rather why I was welcoming the change)
[11:07:07 CEST] <wm4> the other way around is even worse
[11:07:57 CEST] <fritsch> both suck, especially if you try to access Frame fields
[11:08:04 CEST] <JoshX> Hello, I'm looking around in libavformat/matroskaenc.c in mkv_write_packet_internal to add one more field in the meta data (system clock)
[11:08:20 CEST] <JoshX> could anyone point me in a direction to go from here? :)
[11:08:31 CEST] <yann> fritsch: no, I'm just accessing the AVPicture fields in an AVFrame :)
[11:08:32 CEST] <fritsch> isn't systemclock some "runtime dependend" not suited for such a central field?
[11:08:38 CEST] <fritsch> yann: i thought so, yes
[11:08:49 CEST] <fritsch> but you don't know what the api, you might use does
[11:09:20 CEST] <yann> I'm really just using the data myself afterwards
[11:11:23 CEST] <JoshX> fritsch: well.. What I need is for these files to have the system time as unix timestamp available every keyframe for example.. or once a second.. this to synchronize videofiles from different sources later on in software 
[11:11:38 CEST] <wm4> JoshX: does mkv have support for this?
[11:11:46 CEST] <wm4> the format itself, I mean
[11:11:50 CEST] <nevcairiel> doubtful
[11:12:04 CEST] <wm4> nevcairiel: well who knows what these cellar guys are adding
[11:12:11 CEST] <nevcairiel> there is no frame based metadata and i've never seen an element for that
[11:12:55 CEST] <nevcairiel> wm4: its funny how some idiots try to get their wishes implemented through proposing it to cellar, some guy and his crusade for mkv menu support etc =p
[11:13:09 CEST] <nevcairiel> not that it matters if no player ever is going to support it
[11:14:06 CEST] <wm4> did that menu thing advance?
[11:14:11 CEST] <nevcairiel> dont think so
[11:14:16 CEST] <wm4> good
[11:14:43 CEST] <BtbN> An optional system/unix time tag doesn't seem that bad of an idea to me though.
[11:14:52 CEST] <nevcairiel> but they didnt seem entirely opposed either
[11:15:14 CEST] <nevcairiel> BtbN: if the format defines such a field, great, but if it doesn't, we shouldnt try to invent one =p
[11:15:29 CEST] <BtbN> Doesn't mkv support arbitrary metadata?
[11:15:41 CEST] <nevcairiel> global and per track etc, but not per keyframe
[11:15:58 CEST] <BtbN> hm
[11:16:02 CEST] <nevcairiel> you could just define the unix time of the start of the file and then offset it by the timestamps
[11:16:09 CEST] <nevcairiel> not sure why you would need per-frame unix time anyway
[11:19:04 CEST] <BtbN> sure, one timestamp per file seems fine. Unless you are doing something super weird.
[11:19:28 CEST] <yann> fritsch: at least, using an AVFrame provides a quick solution, you're right :)
[11:20:24 CEST] <wm4> yann: what are you trying to do?
[11:22:27 CEST] <yann> wm4: doing an optional colorspace conversion after decoding - I was using an AVPicture internally to store the converted frame data, and an AVPicture* so the display step does not have to bother where the frame data came from
[11:23:42 CEST] <yann> so I switched to an AVFrame, at the cost of unused struct fields (and then, of the risk that someone indeed tries to use the other AVFrame fields one day)
[11:25:57 CEST] <yann> incidentally, I also have some #ifdef'd out imgutils code in there, will have to dig why I did not use it in the end - I remember that some months ago I had hit an API that was too limited, but I'm not sure it was that case - I'll dig all of this when I'll have a bit more time (which may take some undefined number of weeks ;)
[11:26:54 CEST] <wm4> well uh having your own struct for this is only 4 lines
[13:36:25 CEST] <kierank> are there any 10-bit crcs in ffmpeg
[13:50:44 CEST] <durandal_1707> kierank: no, I see only 8, 16, 24 and 32
[13:57:34 CEST] <Daemon404> non-byte multiples of bits for a crc?
[13:58:26 CEST] <kierank> correct
[14:00:50 CEST] <Daemon404> my first thought is "why"
[14:01:25 CEST] <kierank> 10-bit samples
[14:01:27 CEST] <wm4> my second thought is "probably because multimedia"
[14:01:46 CEST] <kierank> Or 20-bit in audio
[14:02:20 CEST] <nevcairiel> cant you just crc the entire buffer, regardless of how its interpreted :D
[14:02:27 CEST] <Daemon404> exactly
[14:02:49 CEST] <atomnuker> no, the polynomial has a 0th power
[14:03:03 CEST] <atomnuker> so for every 0 in the MSB your CRC changes
[14:03:19 CEST] <nevcairiel> and thats bad why?
[14:03:48 CEST] <nevcairiel> just gives you a different number, but it still tells you when anything changes
[14:03:54 CEST] <atomnuker> because it's not going to match what the hardware is going to think it should be
[14:04:03 CEST] <Daemon404> i knew it
[14:04:14 CEST] <Daemon404> "because hardware" - beoadcast
[14:04:19 CEST] <Daemon404> no actual reason
[14:04:57 CEST] <atomnuker> well, I doubt most of the hardware actually checks the CRC since I've seen bitbanged sdi
[14:05:18 CEST] <nevcairiel> in any case, you know your task then
[14:05:32 CEST] <atomnuker> but still, there has to be a CRC and it has to be valid
[14:05:36 CEST] <Daemon404> weeping ailently because he works in broadcast?
[14:05:40 CEST] Action: Daemon404 runs
[14:05:45 CEST] <Daemon404> silently*
[14:05:49 CEST] <iive> how is the 10bit data stored in memory?
[14:05:59 CEST] <kierank> When have you seen bitbanged SDI?
[14:06:00 CEST] <atomnuker> as 16 bits
[14:06:26 CEST] <atomnuker> I remember seeing some SD-SDI video on youtube where some guy implemented it on an fpga
[14:15:59 CEST] <iive> if I remember correctly, one way to implement crc is through doing shift, check for 1 and doing xor.
[14:17:29 CEST] <iive> this means that you could use crc16 for emulating crc10, using shorter polynom and doing probably 6 more "divisions" manually at the finish
[14:17:46 CEST] <iive> this however needs the 10bit data to be packed.
[14:18:21 CEST] <iive> I guess that ffmpeg uses table method with pre-calculated values
[14:19:04 CEST] <iive> I wonder if that could be used to avoid the packing...
[15:03:11 CEST] <cone-657> ffmpeg 03PrzemysBaw Sobala 07master:5fce4753ff0f: avfilter/vf_fps: set fps value boundaries
[15:15:01 CEST] <Daemon404> to fix av_dump cosmetics apply the patch asap?
[15:15:07 CEST] Action: Daemon404 sigjs
[15:22:02 CEST] <cone-657> ffmpeg 03PrzemysBaw Sobala 07master:1a3cff4f7ead: libavutil/opt: add writing AV_OPT_TYPE_VIDEO_RATE AVOption
[15:43:44 CEST] <JoshX> wm4:
[15:43:53 CEST] <JoshX> sorry was away
[15:44:16 CEST] <JoshX> wm4 yes aparently it does, there are certain axis camera's that povide this functionality
[15:44:46 CEST] <JoshX> and it is used in this python packag: vi3o (https://github.com/hakanardo/vi3o)
[15:49:16 CEST] <wm4> JoshX: which ebml elements does it use?
[15:50:00 CEST] <Daemon404> nevcairiel, fyi get_bits64 exists in ffmpeg :P
[15:50:13 CEST] <nevcairiel> Daemon404: never seen that used
[15:50:21 CEST] <Daemon404> it's ffmpeg-specific
[15:51:45 CEST] <JoshX> wm4 i'm trying to find that out myself.. 
[15:52:30 CEST] <Daemon404> JoshX, unrelated but i see a few no-nos in that code
[15:53:01 CEST] <nevcairiel> wm4: it seems to store a index file separately
[15:53:37 CEST] <JoshX> Daemon404: it is from a customer, the use it to synchronise different videofiles and play them side by side or overlayed
[15:53:53 CEST] <JoshX> Daemon404: it synchronises using the system timestamp in the MKV
[15:53:53 CEST] <Compn> mplayer udp slave can do that
[15:54:04 CEST] <Daemon404> sure, i just thought 'd like you know the there's a few api usage problems
[15:54:15 CEST] <Daemon404> let you*
[15:54:23 CEST] <JoshX> cheers :) didn't write it.. 
[15:54:28 CEST] <JoshX> :-)
[15:54:40 CEST] <Daemon404> ;)
[15:54:48 CEST] <JoshX> the customer wants us to use axis camera's for this project because 'axis can store system time per frame'
[15:54:59 CEST] <JoshX> or per keyframe..
[15:55:10 CEST] <Daemon404> thats not really unique to a certain camera
[15:55:29 CEST] <Daemon404> lots of containers can store metadata
[15:55:38 CEST] <JoshX> i guess axis abuses a field and stores the epoch in it every keyframe or so
[15:56:07 CEST] <JoshX> true.. i know mkv can :-) i just don't know (yet) what field is used 
[15:56:11 CEST] <BtbN> And what's the problem with one timestamp per file? Is "start timestamp + playtime" not accurate enough?
[15:56:19 CEST] <JoshX> and then where to build it in my ffmpeg version :)
[15:56:55 CEST] <Daemon404> BtbN, its just the age old story of "proprietary thing uses proprietary way to store normal data that doesnt even need it"
[15:56:55 CEST] <JoshX> BtbN: they want the systemtime so they can compensate for ntp-sync-hops (if that makes any sense)
[15:57:39 CEST] <BtbN> If the one timestamp it has is accurate, how could ntp interfere with that?
[15:58:34 CEST] <JoshX> you cpould detect ntp syncs by comparing the ts of the file (fixed, never changing) to the system time per frame, not fixed, could drift and be re-synced, and then compensate for that when syncing multiple files on top of eachother
[15:58:52 CEST] <JoshX> for example, 2 sides of a road 
[15:59:56 CEST] <Daemon404> i guess it makes sense to have it on the camera itself then
[16:00:05 CEST] <Daemon404> but putting it in some custom field seems dubm
[16:00:07 CEST] <Daemon404> dumb even
[16:00:52 CEST] <JoshX> i know.. but for me it will be 'buying 18 camera's for this specific project, spending 1000s of euro' 
[16:01:06 CEST] <JoshX> or using the setup we alwaysuse with a tweak in code somewhere
[16:01:40 CEST] <Daemon404> ive lost context now, actually, i was musing aloud
[16:01:43 CEST] <BtbN> I still don't understand what NTP has to do with this. The duration of a (micro)second rarely changes.
[16:01:44 CEST] <Daemon404> woops.
[16:02:27 CEST] <BtbN> So if you save the UTC timestamp of the first frame, you have an accurate realtime for every single frame.
[16:02:43 CEST] <JoshX> yes true, that is what i do
[16:03:16 CEST] <JoshX> i patched my ffmpeg to accept a %t in the filename what replaces with a yyyymmdd_hhiissfff
[16:03:31 CEST] <wm4> BtbN: what if there is drift etc.
[16:03:54 CEST] <JoshX> wm4: indeed :)
[16:04:02 CEST] <BtbN> What kind of drift would break video timestamps?
[16:04:06 CEST] <JoshX> then the TS of the file would be sequential and fixed
[16:04:15 CEST] <JoshX> but the systemtime could jump a few msec
[16:04:30 CEST] <JoshX> BtbN: i have videofiles from multiple sources
[16:04:36 CEST] <JoshX> multiple recorders, all ntp synced
[16:04:45 CEST] <JoshX> and a software lib that syncs these files
[16:04:54 CEST] <Daemon404> im with BtbN on this one
[16:04:58 CEST] <JoshX> using the system timestamps stored in the metadata 
[16:05:00 CEST] <flux> the video capture frame rate and the time on the device holding the owlrd time can drift apart from each other, no?
[16:05:07 CEST] <JoshX> yes
[16:05:14 CEST] <BtbN> So make sure the UTC-Timestamp is accurate when it's created, done.
[16:05:32 CEST] <JoshX> so having the system timestamp, with drift, corrections, hops, whatever in lets say every keyframe
[16:05:40 CEST] <Daemon404> maybe theyre doing something dumb like generating timestamps from system time
[16:05:43 CEST] <Daemon404> or something
[16:05:49 CEST] <Daemon404> it should just be basic CFR time stamp generation
[16:05:54 CEST] <JoshX> give me the possibility to sync video files with different lenghts, even framerates and starttimes
[16:05:56 CEST] <Daemon404> then you can still sync with just the one epoch
[16:06:09 CEST] <Daemon404> JoshX, you still only need one system timestamp for that IMO
[16:06:22 CEST] <flux> related: it doesn't seem some video players (ie. mpv) work nicely when the video doesn't start at time zero
[16:06:28 CEST] <nevcairiel> all the corrections could be baked into the frame timestamps
[16:06:34 CEST] <JoshX> from the start of the file, well. yes and no
[16:06:42 CEST] <nevcairiel> flux: matroska requires to start at zero from the spec, fwiw
[16:06:50 CEST] <flux> well, mp4 doesn't (edit lists)
[16:07:07 CEST] <wm4> nevcairiel: haha
[16:07:20 CEST] <BtbN> mp4 likes to be a pain, so that's not overly surprising.
[16:07:26 CEST] <wm4> nevcairiel: I've seen many mkv files that start not from 0
[16:07:37 CEST] <nevcairiel> if its very close to zero its probably fine either way
[16:07:44 CEST] <nevcairiel> but not sure avformat even bothers to fill start_time
[16:07:46 CEST] <wm4> as in not close to 0 at all
[16:08:03 CEST] <flux> I used ths encoding: time from the start of the day.
[16:08:20 CEST] <flux> mpv has option to support this, but it doesn't really work all the way :)
[16:11:10 CEST] <JoshX> hm I have a mkv file now with and without the systemtime in it..
[16:11:56 CEST] <JoshX> its only 36 frames long and it reads:
[16:11:57 CEST] <JoshX> 35
[16:11:57 CEST] <JoshX> 2333000
[16:11:57 CEST] <JoshX> 2.333
[16:11:58 CEST] <JoshX> 1448984846.52
[16:12:07 CEST] <JoshX> which is index, pts, timestamp and system time
[16:12:08 CEST] <BBB> wm4: are you developing mpv?
[16:12:40 CEST] <Daemon404> he is an mpv dev if thats what you mean
[16:12:45 CEST] <BBB> \o/
[16:12:49 CEST] <wm4> yeah
[16:12:56 CEST] <BBB> Invalid video timestamp: 4.100000 -> 4.066667
[16:13:00 CEST] <BBB> why is it doing that?
[16:13:09 CEST] <wm4> timestamp after decoder goes backwards
[16:13:10 CEST] <Daemon404> sounds like non-monotonic timestamps
[16:13:34 CEST] <BBB> which timestamp?
[16:13:44 CEST] <BBB> AVFrame.pkt_pts?
[16:13:46 CEST] <BBB> or & ?
[16:13:54 CEST] <wm4> essentially pkt_pts, yes (in most cases)
[16:14:13 CEST] <JoshX> hmm if there is no 'epoch/systemtime' in the file, the tool outputs the systemtime and timestamp as the same.. so it reads the epoch from some field whichis usually 0 but increases in the file
[16:14:33 CEST] <Daemon404> that sounds all sorts of broken
[16:14:53 CEST] <JoshX> Daemon404: agreed :-/ i just have to roll with it for now..
[16:15:12 CEST] <wm4> BBB: is it a mkv/vp9 file? try with --demuxer=lavf
[16:15:52 CEST] <BBB> same issue with --demuxer=lavf
[16:15:59 CEST] <BBB> its a ivf/vp9 file
[16:16:24 CEST] <wm4> next step is probably checking with ffprobe -show_frames what the decoder outputs
[16:18:42 CEST] <ubitux> i have this invalid ts all the time with webradio
[16:18:51 CEST] <ubitux> but i think i reported it already :p
[16:21:08 CEST] <BBB> its linked to an old libavcodec :(
[16:21:12 CEST] <BBB> ok will tell them to upgrade
[16:22:44 CEST] <durandal_1707> what? Who?
[16:28:17 CEST] <wm4> ubitux: where?
[16:28:29 CEST] <wm4> ubitux: oh, ogg streams?
[16:29:22 CEST] <ubitux> wm4: yeah
[16:30:25 CEST] <wm4> well it would be nice if ffmpeg had some sort of discontinuity flag
[16:32:29 CEST] <BBB> wm4: thanks btw
[16:36:11 CEST] <Daemon404> wm4, wouldnt that only work for formats with frame durations
[16:37:01 CEST] <wm4> Daemon404: depends; my thinking is that the demuxer is in a much better position to know
[16:40:05 CEST] <Daemon404> it would only be possible for some formats ofc
[16:55:28 CEST] <BBB> I think its mildly amusing how some devs think its totally ok to have a variable called properties in a struct called parameters and not be confusing at all
[16:55:38 CEST] <BBB> we did all take engineering 101 right?
[16:55:55 CEST] <BBB> maybe s/amusing/worrying/
[16:56:27 CEST] <wm4> where
[16:57:00 CEST] <wm4> oh, there
[16:57:09 CEST] <BBB> yes, there
[16:57:35 CEST] <BBB> does any avfilter person want to review vf_colorspace: make whitepoint adaptation mode configurable. so I can commit the whole patch-set?
[17:06:50 CEST] <Shiz> BBB: needs to be of typedef attributes to make it complete
[17:07:17 CEST] <BBB> Shiz: totally
[17:08:00 CEST] <durandal_1707> there are no avfilter persons
[17:31:18 CEST] <pfelt> good morning everyone!  hope you all had a great weekend
[17:33:51 CEST] <cone-657> ffmpeg 03Diego Biurrun 07master:01621202aad7: build: miscellaneous cosmetics
[17:33:52 CEST] <cone-657> ffmpeg 03Derek Buitenhuis 07master:ca5ec2bf51d8: Merge commit '01621202aad7e27b2a05c71d9ad7a19dfcbe17ec'
[17:41:16 CEST] <durandal_1707> awful weekend
[17:41:51 CEST] <nevcairiel> wow debian switches to i686, and only because the kernel forces them =p
[17:42:24 CEST] <wm4> revolutionary
[17:42:52 CEST] <nevcairiel> i'm sure there is an outcry with the i386 crowd somewhere :p
[17:45:18 CEST] <DHE> it is somewhat well known that linux dropped 386 compat a year or two ago (iirc)
[17:45:33 CEST] <DHE> but shouldn't 486 and 586 still work?
[17:46:30 CEST] <philipl> It's apparently the compiler, not the kernel.
[17:46:39 CEST] <DHE> ... odd..
[17:46:55 CEST] <nevcairiel> 4.3 kernel requires a newer gcc which apparently only does i686 now
[17:48:47 CEST] <pfelt> alas.  i must finally upgrade my machine i dual boot between linux and dos 6.22
[17:49:11 CEST] <pfelt> i suppose i shoudl upgrade the cga monitor on it too
[17:50:25 CEST] <pfelt> so on the serious side.  i was reading a thread off the email list and it was mentioned that there is a merge queue somewhere.  is that something that i can see? (just curious)
[17:51:48 CEST] <wm4> the merge queue is all commits in Libav master that are not in FFmpeg master
[17:52:19 CEST] <pfelt> so, being new here, how does this all work?  i've been on other projects, but nothing this *big*
[17:52:37 CEST] <pfelt> say i submit a patch, what happens to it then?
[17:53:29 CEST] <Daemon404> pfelt, it gets reviewed and pushed if it is accepted?
[17:53:33 CEST] <Daemon404> merges are unrelated to this
[17:54:10 CEST] <pfelt> ah.  ok.  i assumed they were the same thing.  (i'm not too familiar with git)
[17:55:06 CEST] Action: pfelt will make some time to read https://ffmpeg.org/developer.html#Contributing today
[17:59:06 CEST] <wm4> if you submit a patch you're either asked to make certain changes, or it gets applied to git master
[17:59:08 CEST] <wm4> simple
[18:00:16 CEST] <nevcairiel> and if you dont hear from anyone, just ping it after a period of some days
[18:00:46 CEST] <nevcairiel> it greatly helps to include a rationale in the commit message, so others understand why a change happens
[18:00:51 CEST] <nevcairiel> many people dont do that unfortunately
[18:02:18 CEST] <Daemon404> 'fix bug'
[18:02:18 CEST] <pfelt> i'm not sure i did a good job on the one i submitted on friday night
[18:02:42 CEST] <pfelt> definitely didn't do a good job on the one from a few weeks back (i'm still trying to work out that patch on my end of it)
[18:03:38 CEST] <pfelt> i *did* however figure out the git format-patch that clement pointed me at)
[18:06:21 CEST] <durandal_1707> Nobody put into log "fix bug" anymore
[18:06:46 CEST] <wm4> durandal_1707: many commit messages that are done these days aren't much better though
[18:07:34 CEST] <durandal_1707> my commit messages are perfect
[18:07:39 CEST] <pfelt> hehe
[18:07:40 CEST] <Daemon404> i ran into this just today
[18:07:42 CEST] <Daemon404> with f5074dd39ca3bc6bff96cafea1d723cf944f50e5
[18:07:49 CEST] <Daemon404> no explanation at all when i blame'd the file
[18:10:36 CEST] <durandal_1707> Daemon404: what's it about?
[18:30:34 CEST] <jamrial_> Daemon404: poke me if you want/need help with d12b5b2f135aade4099f4b26b0fe678656158c13 (test programs splitting) for the modules not available on libav
[18:30:38 CEST] <jamrial_> i wrote a couple after all
[18:30:50 CEST] <Daemon404> i havent started evem
[18:30:59 CEST] <Daemon404> or even looked at it
[18:31:01 CEST] <Daemon404> will it be painful
[18:31:10 CEST] <jamrial_> no
[18:31:24 CEST] <Daemon404> ok
[18:31:32 CEST] <jamrial_> but it's five or so modules they don't have
[18:31:49 CEST] <jamrial_> it's just moving the #ifdef TEST part of each module to a separate file
[18:32:26 CEST] <Daemon404> ah ok
[18:59:28 CEST] <jkqxz> Daemon404:  Woo, thanks for merging all of that :)  (And apologies for being away when it might have been useful.  Oh well.)  I guess I'll test all the bits now to make sure I haven't introduced something which doesn't work in ffmpeg...
[19:00:48 CEST] <Daemon404> thank you
[19:01:11 CEST] <Daemon404> im not very happy with how i did ffmpeg_filter.c but it seems to work
[19:01:14 CEST] <Daemon404> i think.
[19:01:18 CEST] <Daemon404> pls do test
[19:29:37 CEST] <Easyfab> durandal_1707: here the bug report for delogo   it's my first report so I don't know if it's ok ? tell me if you need something else.
[19:32:18 CEST] <jkqxz> Looks like it works plausibly.  For decode, fate-h264 passes everything except for the top/left cropping, monochrome and lossless samples (the expected result; monochrome is probably fixable if it matters).
[19:38:10 CEST] <jamrial_> kierank: how's fuzzing?
[19:38:35 CEST] <kierank> So good I don't believe the results
[19:39:47 CEST] <jamrial_> haha
[20:00:35 CEST] <Easyfab> Oh new VAAPI H.264 encoder :) i will try on my nuc
[20:01:43 CEST] <Daemon404> jkqxz, ok
[20:06:47 CEST] <BtbN> it looks as horribly painful as I'd have imagined it.
[20:08:16 CEST] <BtbN> is full hw transcode with vaapi now possible, or will it still pull the frames to system memory?
[20:09:05 CEST] <wm4> hm I think it should be? maybe
[20:09:30 CEST] <BtbN> With the ffmpeg cli i mean. If there is no filter in between, it should never convert the VAAPI frames?
[20:10:07 CEST] <wm4> yeah
[20:10:17 CEST] <wm4> but good question whether it's implemented yet
[20:10:19 CEST] <jkqxz> It is possible.  It is annoying to make it work through lavfi, and you probably want to wait for the next merge making a encoder a bit more usable.
[20:10:22 CEST] <durandal_1707> Easyfab: what compiler ?
[20:13:22 CEST] <jkqxz> (You can use something like './ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i ... -vf 'format=nv12|vaapi,hwupload,scale_vaapi=w=1280:h=720' -c:v h264_vaapi ...' to transcode with scaling, for example.)
[20:14:10 CEST] <wm4> so the next step is a vpp filter I guess
[20:14:21 CEST] <durandal_1707> why those hw filters are not documented?
[20:15:37 CEST] <Easyfab> durandal_1707: gcc (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413 and gcc 5.3.0 when cross-compiling for windows
[20:16:05 CEST] <BtbN> jkqxz, hwupload/download is what I'd like to avoid.
[20:18:21 CEST] <jkqxz> The hwupload isn't actually doing anything there in the normal case.  It's required because of the two-step graph setup, and will only be actually uploading frames if you fall back to software decode because the input wasn't supported.
[20:18:42 CEST] <durandal_1707> Easyfab: and the crash happens on both?
[20:18:52 CEST] <Easyfab> yes
[20:20:24 CEST] <durandal_1707> Easyfab: does crash happens with specific input combinations? Or any input works?
[20:21:07 CEST] <Easyfab> one moment i will try with different format.
[20:29:55 CEST] <Easyfab> yes all videos but not with -vf  delogo=x=0:y=0:w=2:h=2 as I report but with w=20:h20 or greater 
[20:38:50 CEST] <durandal_1707> Easyfab: so it happens with pure white video?
[20:41:06 CEST] <Easyfab> how can I test that ?
[20:44:52 CEST] <durandal_1707> ffmpeg -f lavfi -i color -vf delogo...
[20:48:15 CEST] <llogan> color=c=white
[20:50:53 CEST] <Easyfab> same error Exception en point flottant (core dumped)   http://pastebin.com/eMMHqQcW
[20:59:39 CEST] <Easyfab> durandal_1707:  Must be my computer ( i2600K) because on my nuc ( braswell) it works :(
[21:00:45 CEST] <Easyfab> Can it be tha asm AVX or something like that ?
[21:01:23 CEST] <jamrial_> try using -cpuflags 0 to make sure
[21:03:04 CEST] <relaxed> happens here too (with -cpuflags 0)
[21:03:53 CEST] <Easyfab> so I'm not alone :)
[21:12:57 CEST] <llogan> anyone here w/ gcc 6.1.1?
[21:20:24 CEST] <rcombs> is there some equivalent to RGB_TO_[YUV]_CCIR that works with an arbitrary YUV colorspace?
[21:22:01 CEST] <nevcairiel> no
[21:22:12 CEST] <llogan> nevermind. i can't seem to duplicate the "gcc: internal compiler error: Bus error (program cc1)"
[21:22:27 CEST] <nevcairiel> its an 8-bit integer approximation anyway, you may not want it for anything important
[21:23:29 CEST] <rcombs> trying to get ff_draw to support non-BT601 YUV
[21:25:33 CEST] <rcombs> right now my hacked-up subtitle overlay filter does some ridiculous shit copied from mpv involving converting to YUV and then back (made more complex by VSFilter compatibility)
[21:26:24 CEST] <wm4> mpv uses libswscale for doing this (qualifies as ridiculous shit)
[21:28:07 CEST] <Shiz> can confirm
[21:28:21 CEST] <rcombs> wm4: I'm referring to mangle_colors in sd_ass.c
[21:28:33 CEST] <wm4> ah, yeah, vsfilter compat
[21:30:45 CEST] <rcombs> not sure if that would still be necessary with ff_draw support for non-601 colorspaces, since vsfilter compat is some pretty arcane shit
[21:32:24 CEST] <wm4> this compat is always necessary
[21:32:48 CEST] <wm4> since subs can be color mangled or not, depending on circumstances and ass header
[21:33:21 CEST] <wm4> you could probably get away with hardcoding the two common cases
[21:33:33 CEST] <rcombs> wm4: in ff_draw, I'm wondering if it could be implemented as simply as "blend YUV as if the destination color space were <the one in the ASS header>"
[21:33:44 CEST] <Daemon404> the only reason you would ever care about vsfilter compat is for playing anime. ever.
[21:33:48 CEST] <Daemon404> afaik.
[21:33:51 CEST] <wm4> rcombs: sounds correct
[21:34:06 CEST] <wm4> and what Daemon404 said
[21:34:28 CEST] <Daemon404> wm4, just think. there was once a time where fansubs were that important to me.
[21:34:30 CEST] <rcombs> rather than going RGB->(ASS header CSP)->RGB mangled->(ffdraw)YUV mangled
[21:34:40 CEST] <Daemon404> that time was, of course, high school / undergrad
[21:34:49 CEST] <Daemon404> i cringe now thinking of the ridiculous hacks
[21:35:40 CEST] <rcombs> either way, ff_draw clearly shouldn't hardcode BT601
[21:35:48 CEST] <rcombs> even putting aside all the dumb hacks
[21:36:10 CEST] <Daemon404> ofc
[21:36:20 CEST] <JEEB> I think no header = BT.601 basically, otherwise follow the crazy bullshit logic gained from the xy-vsfilter added headers
[21:36:29 CEST] <durandal_1707> yes, tell that to lazy devs
[21:36:59 CEST] <wm4> rcombs: the ass header basically tells you what video colorspace aegisub was assuming, I think
[21:37:04 CEST] <rcombs> so I figured I'd work out how to support arbitrary colorspaces (at least, ones we have enum values for), and then see if I still need to mangle colors within my filter
[21:37:24 CEST] <wm4> mpv does it only this way because subtitles are _actually_ rendered in RGB most of the time
[21:37:36 CEST] <rcombs> yeah that's a bit more sane
[21:37:47 CEST] <rcombs> my case here is rendering on YUV video so it gets a bit more crazy
[21:38:26 CEST] <rcombs> also nevcairiel ff_draw does support >8-bit precision& and does it by left-shifting the 8-bit approximation by (bits-8)
[21:38:27 CEST] <wm4> yeah, but the implementation of the vsfilter compat becomes easier
[21:38:38 CEST] <rcombs> so I'd like to stop doing that as well
[21:38:48 CEST] <Daemon404> i wonder how many ad-hoc yuv2rgb/rgb2yuv are in ffmpeg
[21:38:53 CEST] <rcombs> a lot!
[21:38:53 CEST] <Daemon404> to avoid making a sws dependency
[21:38:58 CEST] <Daemon404> because reasons
[21:39:19 CEST] <rcombs> this one is sorta awkward because most of the existing ones are meant for entire images
[21:39:25 CEST] <rcombs> and here I want just one color value converted
[21:39:39 CEST] <rcombs> inb4 1x1px bitmap
[21:39:43 CEST] <Daemon404> rcombs, there are multiple yuv-based codecs with rgb cursors
[21:39:44 CEST] <Daemon404> in avcodec
[21:39:47 CEST] <Daemon404> 32x32
[21:39:48 CEST] <Daemon404> ;)
[21:40:14 CEST] <Daemon404> actually g2m might have different colorspaces per-tile
[21:40:15 CEST] <Daemon404> iirc
[21:40:27 CEST] <rcombs> wew
[21:40:42 CEST] <rcombs> I might have to stick something in lavu :/
[21:41:01 CEST] <rcombs> https://xkcd.com/927/
[21:41:19 CEST] <wm4> also there's vf_colorspace
[21:41:25 CEST] <wm4> aka libswscale2
[21:41:35 CEST] <Daemon404> and vf_zscale
[21:41:51 CEST] <rcombs> or maybe just move the vf_colorspace functions to colorspace.c/.h
[21:41:53 CEST] <Daemon404> also teh xyz code used to be in lavfi
[21:41:57 CEST] <Daemon404> but i think it went into sws now
[21:42:14 CEST] <rcombs> or use swscale (no qualms about this if it's workable for a single value)
[21:42:26 CEST] <Daemon404> this is just one of those things i try not to think about
[21:42:35 CEST] <Daemon404> and pray it doesnt affect me
[21:42:35 CEST] <rcombs> though >swscale >still having its own set of enums for everything
[21:43:02 CEST] <wm4> rcombs: you could scale a single pixel
[21:43:11 CEST] <wm4> just to do the conversion
[21:43:16 CEST] Action: wm4 wonders about the overhead
[21:43:18 CEST] <rcombs> yeah, I said that earlier
[21:44:22 CEST] <Daemon404> you need to make sure to align the buffer for that single pixel btw
[21:44:30 CEST] Action: Daemon404 runs
[21:44:46 CEST] <Easyfab> jkqxz: with your command line example( without scale )  -c:v h264_vaapi works nicely at 29fps on my braswell for 1080p video  vs 21fps for x264 superfast but qualty is not as good. I see that in the gstreamer h264_vaapi plugins you can set cabac=true, bframes, tune=high-compression ... Can we yet acess this option in ffmpeg 
[21:45:44 CEST] <wm4> didn't he say something like this will get merged from Libav
[21:46:04 CEST] <nevcairiel> probably, there is a bunch of improvements scheduled for later
[21:48:00 CEST] <nevcairiel> kurosu: did you delete your post from the doom9 thread about decoding speed, or did one of the mods not like calling out another mod on the topic?
[21:48:47 CEST] <pfelt> slightly OT question.  if i'm working on a change that's dependent upon a patch, that's already been submitted but not accepted yet, is the best way to work that on my local codebase to branch off the branch that i wrote that base patch in?
[21:49:18 CEST] <Shiz> vf_swscale
[21:49:48 CEST] <wm4> Shiz: vf_scale?
[21:52:24 CEST] <Daemon404> kurosu is on doom9?
[21:52:30 CEST] <Daemon404> news to me and ive been a member since 05
[21:52:31 CEST] <Daemon404> O.o
[21:53:40 CEST] <nevcairiel> was the same name and he linked the thread here the other day, so i assume its him =p
[21:53:57 CEST] <nevcairiel> but the post now vanished, so
[21:54:12 CEST] <Daemon404> is there a poitn to d9 anymore?
[21:54:16 CEST] <Daemon404> it mostly seems like insane people now
[21:54:25 CEST] <Daemon404> or people who dont really know what theyre talking about
[21:55:00 CEST] <nevcairiel> the second kind is present everywhere
[21:55:10 CEST] <iive> has it ever been different?
[21:55:30 CEST] <iive> I remember some x264 developers creating doom10 to fix that.
[21:55:40 CEST] <Daemon404> doom10 wasnt created for that
[21:55:49 CEST] <Daemon404> doom10 was created because dark_shikari hated neuron2.
[21:56:17 CEST] <Daemon404> there was a huge falling out thread regarding the 2 and ffmpeg's license violators page of shame
[21:56:21 CEST] <Daemon404> anyway d10 is dead now.
[21:57:04 CEST] <nevcairiel> d10 never was alive, really
[21:57:19 CEST] <JEEB> it had random activity for a very short point in time
[21:57:40 CEST] <Daemon404> about 40% of that activity was troll threads about n2
[21:58:09 CEST] <JEEB> I think there were then some people who just kept posting there while always making sure to mention how much better it is than d9 because of no n2
[21:58:39 CEST] <nevcairiel> he left a couple years ago anyway, so
[21:58:40 CEST] <Shiz> what programs still output this shit even
[21:58:46 CEST] <Shiz> whoops i was scrolled up
[21:58:51 CEST] <Daemon404> nevcairiel, he is still around under a diff nick
[21:58:52 CEST] <Shiz> i meant the ridic vsfilter headers
[21:59:04 CEST] <nevcairiel> Daemon404: yeah but he isnt a mod anymore that actively seeks out to screw people
[21:59:05 CEST] <JEEB> Shiz: they're the default thing nowadays
[21:59:27 CEST] <JEEB> aegisub by default will write them and xy-vsfilter (still) will happily take them in
[21:59:32 CEST] <Shiz> :|
[21:59:37 CEST] <Shiz> can you make it not do that
[21:59:41 CEST] <Daemon404> the anime community is both the reason we can, and can't, have nice things
[21:59:49 CEST] <Plorkyeran> aegisub always writes the header because even with insane compat mode off aegisub may have used the wrong colorspace
[21:59:50 CEST] <nevcairiel> half of his activity was locking any threads were the creator didn't name the source of his video file, on suspicion of piracy =p
[21:59:57 CEST] <wm4> Daemon404: which nice things
[22:00:01 CEST] <Daemon404> wm4, x264
[22:00:03 CEST] <wm4> that we can have
[22:00:14 CEST] <Plorkyeran> the insane compat mode was supposed to be disabled a year or two ago but I haven't actually made any releases in in like 18 months
[22:00:15 CEST] <wm4> x264?
[22:00:17 CEST] <Plorkyeran> so
[22:00:28 CEST] <Daemon404> wm4, where do you think pengvado or D_S came from
[22:00:30 CEST] <Shiz> D_S was ridiculously weeb after all
[22:00:37 CEST] <wm4> eh
[22:01:05 CEST] <JEEB> I still remember the zx post pengvado's number-crunched lavc mpeg4 encode
[22:01:08 CEST] <nevcairiel> i never understood this obsession with anime
[22:01:09 CEST] <JEEB> *post on
[22:01:11 CEST] <nevcairiel> whats up with those people
[22:01:28 CEST] <nevcairiel> for most, in a language you don't even understand
[22:01:33 CEST] <Shiz> man an ffmpeg dev asking that is just the funniest thing
[22:01:37 CEST] <Daemon404> whats up with people's obsession with guns? 
[22:01:40 CEST] <Daemon404> people are people.
[22:02:38 CEST] <JEEB> and you even had people like mentar or rika who were/are still in that stuff in their N0ties
[22:02:56 CEST] <iive> nevcairiel: japan actually produces a lot of anime, and occasionally some of it is great.
[22:03:18 CEST] <Shiz> don't liw
[22:03:21 CEST] <Shiz> lie
[22:03:28 CEST] <llogan> i've seen one. akira i think is what it is called.
[22:03:41 CEST] <iive> yeh, it is classic.
[22:03:41 CEST] <Daemon404> so nothing sicne teh 80s?
[22:03:43 CEST] Action: Daemon404 runs
[22:03:53 CEST] <JEEB> anyways, herp derp people have their "things" so (´4@)
[22:03:57 CEST] <Plorkyeran> anime has incredibly unthreatening cute girls
[22:04:02 CEST] <Plorkyeran> what's not to get
[22:04:13 CEST] <nevcairiel> i've watched maybe one or two animes that got translated either to english or even german, but i never would both with reading subtitles and hearing japanese
[22:04:14 CEST] <Daemon404> Plorkyeran, when they give these girls horribly grating voices and personalities
[22:04:17 CEST] <Daemon404> thats when i dont get it.
[22:04:21 CEST] <nevcairiel> bother*
[22:04:39 CEST] <Daemon404> anyway its just people's hobbies
[22:04:40 CEST] <iive> well, anime have a wide range of themes. SciFi is easy when effects doesn't cost extra
[22:04:47 CEST] <rcombs> Plorkyeran: and also threatening ones
[22:04:57 CEST] <Daemon404> id argue people who enjoy foss multimedia as a hobby are just as 'odd'
[22:05:00 CEST] <Daemon404> perhaps odder.
[22:05:05 CEST] <Daemon404> its much more niche.
[22:05:18 CEST] <nevcairiel> i just started because there was no player that did what I wanted
[22:05:32 CEST] <rcombs> isn't that how most FOSS happens
[22:05:45 CEST] <rcombs> "I want software that does $thing; no software does $thing"
[22:06:20 CEST] <nevcairiel> ie. before me the windows player world was rather crappy, people either used ancient and broken ffdshow versions or vlc which just didnt do windows well back then
[22:06:30 CEST] <Plorkyeran> sometimes it's more of "I want software that does $thing; software exists that does $thing but it has some trivial problem so I'm going to write my own from scratch"
[22:06:34 CEST] <Daemon404> rcombs, close
[22:06:38 CEST] <Shiz> NIH yo
[22:06:44 CEST] <Daemon404> you forgot "exisiting software is crappy"
[22:06:48 CEST] <JEEB> nevcairiel: -tryouts YOOOOOO
[22:06:48 CEST] <Daemon404> or "gpl v3"
[22:06:58 CEST] <llogan> for me i simply got tired of not knowing how to encode stuff
[22:06:59 CEST] <JEEB> last touched that piece of crap in '11
[22:06:59 CEST] <Shiz> Daemon404: alternatively "not gpl v3"
[22:07:04 CEST] <Shiz> depends on who you are
[22:07:18 CEST] <rcombs> or "it does $thing1 and another program does $thing2, but nothing does both"
[22:07:28 CEST] <JEEB> so yeah, LAV brought a lot of relative sanity into DShow
[22:07:31 CEST] <nevcairiel> JEEB: lav started in 2010, so its been a while
[22:07:45 CEST] <Daemon404> ffdshow is not dead
[22:07:50 CEST] <Daemon404> people still use it for its avs filtering
[22:07:55 CEST] <Daemon404> sadly.
[22:07:57 CEST] <JEEB> yes, unfortunately
[22:08:00 CEST] <nevcairiel> some crazies use it for postprocessing or avs yeah
[22:08:07 CEST] <JEEB> and clsid2 probably still gives it a commit or so every Nth month
[22:08:13 CEST] <JEEB> if he still gives a fuck
[22:08:15 CEST] <nevcairiel> but its filtering stuff isn't quite as insane as its decoders
[22:08:18 CEST] <nevcairiel> (still bad tho)
[22:09:20 CEST] <nevcairiel> there is the odd commit now and then, but ffmpeg hasnt been updated in years in it, and you can count the number of commits in the last 3 years on one hand, so
[22:09:33 CEST] <JEEB> yeah, that's how I last saw it
[22:09:44 CEST] <JEEB> and the libavcodec there is a weird mess
[22:09:50 CEST] <JEEB> mishmash of libav and ffmpeg IIRC
[22:09:55 CEST] <nevcairiel> i pondered writing an avisynth or vapoursynth filter one day
[22:09:59 CEST] <nevcairiel> but i just dont fucking care :D
[22:10:16 CEST] <JEEB> yeah, if you have no use case then welp
[22:10:58 CEST] <Daemon404> [21:09] <+JEEB> mishmash of libav and ffmpeg IIRC <-- you forgot the hacks
[22:11:05 CEST] <JEEB> yes
[22:11:34 CEST] <nevcairiel> fixing ffdshow was literally impossible due to the amount of crap and hacks it collected over the years
[22:11:43 CEST] <nevcairiel> so from scratch it was
[22:11:45 CEST] <JEEB> ayup
[22:12:19 CEST] <Daemon404> nevcairiel, out of curiosity what didnt it 'do' that you wanted
[22:12:27 CEST] <nevcairiel> i forget
[22:12:30 CEST] <nevcairiel> probably "work"
[22:12:40 CEST] <Daemon404> lol.
[22:12:47 CEST] <nevcairiel> i actually started with a demuxer, since that didnt exist based on avformat
[22:13:37 CEST] <nevcairiel> and I already had a video decoder based on the nvidia cuvid sdk .. so at that point it just appeared logical to make a ffmpeg decoder as well thats not quite as hacky
[22:13:45 CEST] <nevcairiel> (although its dshow, a certain number of hacks is a given)
[22:14:17 CEST] <jamrial_> nevcairiel: before you people used bsplayer :p
[22:14:19 CEST] <Daemon404> it was vfw too
[22:14:23 CEST] <Compn> nevcairiel : i think the reason you wonder about anime is because you were not around during the "golden age" of the 1990s anime (being fansubbed in early 2000s)
[22:14:29 CEST] <JEEB> people *still* seem to use bsplayer
[22:14:39 CEST] <JEEB> for some reason
[22:14:44 CEST] <nevcairiel> isnt bsplayer one of those that just steal from me
[22:14:55 CEST] <Daemon404> i dunno but it predated you
[22:14:59 CEST] <JEEB> not sure, I never looked into it
[22:14:59 CEST] <Daemon404> and had skins
[22:15:03 CEST] <JEEB> yeah
[22:15:16 CEST] <JEEB> I used it in like... 2003-4? for some periods of time
[22:15:16 CEST] <nevcairiel> that doesnt mean much, some older players keep magically having the same  advances shortly after me
[22:15:34 CEST] <JEEB> my friend still uses bsplayer because of the subtitle downloader I think
[22:15:48 CEST] <Daemon404> doesnt mpc have that
[22:15:50 CEST] <Daemon404> oo
[22:15:50 CEST] <nevcairiel> someone stole my h264 mvc stuff for some kodi branch, well he kept attribution in the source files so its probably fine, but it would be nice to be told such things =p
[22:15:50 CEST] <Daemon404> too
[22:16:17 CEST] <nevcairiel> Daemon404: it does, and it got reworked quite a lot recently to support more services
[22:16:26 CEST] <JEEB> Daemon404: yeah but it was something like "b-b-b-but mpc-hc doesn't just let you press a butan and auto-get a subtitle!"
[22:16:39 CEST] <JEEB> you had more menus in mpc-hc or something
[22:16:40 CEST] <JEEB> idk
[22:31:27 CEST] <Compn> BUFFERING
[22:33:05 CEST] <kurosu> Daemon404, I've been since '02, but stopped participating a long time ago
[22:33:34 CEST] <kurosu> nevcairiel, it was a bit too hot-blooded, and not going to achieve anything
[22:33:49 CEST] <kurosu> so I deleted it
[22:33:55 CEST] <nevcairiel> i see
[22:34:01 CEST] <nevcairiel> true nevertheless
[22:36:38 CEST] <Daemon404> what did i miss?
[22:36:44 CEST] <Daemon404> sounds at least interesting
[22:37:31 CEST] <kurosu> I don't really know, but among all those streaming websites/services/..., amazon is likely the least "thankful"
[22:37:36 CEST] <nevcairiel> he called out an employee of amazon video for complaining about hevc decode speed, and told him to go instead motivate his employer to pay
[22:37:53 CEST] <kurosu> s/is likely/looks to me/
[22:38:06 CEST] <Daemon404> nevcairiel, ben waggoner>
[22:38:07 CEST] <Daemon404> ?
[22:38:10 CEST] <nevcairiel> yea
[22:38:29 CEST] <kurosu> previously microsoft employee, iirc ?
[22:38:33 CEST] <nevcairiel> i think so
[22:39:01 CEST] <Daemon404> kurosu, i'd argue youtube or netflix
[22:39:07 CEST] <Daemon404> probably netflix.
[22:39:18 CEST] <Daemon404> though at least netflix admits they use ffmpeg.
[22:39:32 CEST] <wm4> who doesn't admit it?
[22:39:42 CEST] <Daemon404> youtube has never admitted it publically
[22:39:50 CEST] <nevcairiel> we should add subtle bugs to your muxers and analyze their files =p
[22:39:57 CEST] <kurosu> yeah, I'm not sure how much aiv actually uses ffmpeg (well, except the rationale "what are they gonna use then?")
[22:39:59 CEST] <durandal_1707> Gooble
[22:40:29 CEST] <kurosu> subtle bugs, or subtle bitstream manipulations like in padding ? :)
[22:40:31 CEST] <Daemon404> kurosu, i assume they do. elastic transcode does for example.
[22:40:39 CEST] <Daemon404> i dont think the guy on d9 (ben) codes though
[22:40:41 CEST] <Daemon404> he is a manager iirc
[22:40:49 CEST] <kurosu> yeah, he is
[22:40:50 CEST] <nevcairiel> even better position to get us funds =p
[22:41:19 CEST] <Daemon404> i would be hard pressed to get my employer to pay funds directly to libav*
[22:41:19 CEST] <kurosu> he's probably quite knowledgeable about x265 commercial licenses, too :)
[22:41:23 CEST] <Daemon404> but we contribute in dev work
[22:41:25 CEST] Action: Daemon404 hides
[22:41:26 CEST] <durandal_1707> Gstreamer
[22:41:41 CEST] Action: wm4 wonders what nevcairiel works for
[22:41:45 CEST] <Daemon404> kurosu, he's been quite a hevc advocate even before it was at all useful
[22:42:01 CEST] <kurosu> as long some modifications are published, it's already a good trade 
[22:42:05 CEST] <Daemon404> i used to be too. until the patent-ning happened.
[22:42:11 CEST] <Daemon404> now i simply cannot.
[22:42:50 CEST] <wm4> so what is it going to be, vp9, or one of those endless vapor codecs
[22:43:01 CEST] <Daemon404> kurosu, youtube has send some patches here and there. netflix sent 1 line... once.
[22:43:04 CEST] <Daemon404> ;)
[22:43:07 CEST] <jamrial_> Daemon404: now you're a daala advocate then? :P
[22:43:27 CEST] <Daemon404> jamrial_, no i just think the situation we're in for "next gen" video is bad.
[22:43:30 CEST] <kurosu> web streaming will use vp9, but still need patented tech for hdr
[22:43:46 CEST] <JEEB> HDR is one of the best messes I've seen in a while
[22:43:54 CEST] <JEEB> at least it doesn't touch the actual video stream too much
[22:43:54 CEST] <kierank> kurosu: HLG?
[22:43:54 CEST] <Daemon404> we're in a weird situation where the best case may be a proprietary encoder for vp9
[22:43:55 CEST] <kurosu> and then we'll see how many patent trolls exist in the field of video coding
[22:43:55 CEST] <kierank> that's patent free
[22:43:58 CEST] <nevcairiel> vp9 in itself isnt a bad codec, just libvpx sucks .. wonder how BBB's new encoder can change things, but right now there doesnt seem much of a market for it
[22:44:02 CEST] <Daemon404> which, if you asked me 2 years ago, was impossible.
[22:44:17 CEST] <jamrial_> BBB is writing a vp9 encoder?
[22:44:22 CEST] <kurosu> kierank, that's just BBC/ARIB and not yet used (maybe uhd phase 2?)
[22:44:30 CEST] <Daemon404> jamrial_, he made the info public last week
[22:44:36 CEST] <wm4> jamrial_: it's proprietary
[22:44:39 CEST] <BBB> ?
[22:44:51 CEST] <BBB> jamrial_: yes
[22:44:52 CEST] <JEEB> yes, 2 years ago the look on the market was quite different
[22:44:57 CEST] <kierank> kurosu: afaik it's supported on some tvs and you could build a  working pipeline
[22:45:02 CEST] <Daemon404> 2 years ago i was sure hevc would win
[22:45:04 CEST] <Daemon404> look at me now.
[22:45:06 CEST] <Daemon404> egg on my face.
[22:45:18 CEST] <BBB> and sorry that its proprietary but I need to make a living somehow :-/
[22:45:39 CEST] <wm4> BBB: nobody accused you yet
[22:45:44 CEST] <JEEB> nobody's really herping a derp at you for that :P
[22:45:45 CEST] <jamrial_> BBB: do you have a blog post or something about it?
[22:45:46 CEST] <wm4> of the dirty crime of trying to make a living
[22:45:52 CEST] <BBB> jamrial_: https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/
[22:45:57 CEST] <jamrial_> thanks
[22:46:04 CEST] <kierank> blame web streamurs for being freeloaders
[22:46:05 CEST] <kurosu> kierank, we'll see in 3-4 years when it's actually deployed - but like JEEB said it's just another one
[22:46:06 CEST] <durandal_1707> ban him!
[22:46:08 CEST] <kierank> at least broadcasters pay
[22:46:51 CEST] <Daemon404> wm4, the real foss way is to work an unrewarding job at google as an extremely overqualified tech support guy, and work on your projects that are fundemntal to like 900 bisiness, on your fere time
[22:46:55 CEST] <Daemon404> right
[22:46:58 CEST] <Daemon404> ?
[22:47:01 CEST] <JEEB> I wonder if there's any actual BT.2020 utilizing content out there on that one Japanese satellite channel that's now been in production mode for a while
[22:47:23 CEST] <nevcairiel> BBB: btw the quality comparisons you did seem a bit lacking, not including hevc and the choice of resolutions seems like 3 years ago
[22:47:34 CEST] <JEEB> last time I checked it was just a test channel for ARIB's specified BT.709->BT.2020 rulebook
[22:48:28 CEST] <wm4> Daemon404: wat
[22:48:28 CEST] <durandal_1707> how much fast is this encoder?
[22:48:46 CEST] <BBB> nevcairiel: Id love to do more 4k but the encoder is still quite slow
[22:48:51 CEST] <Daemon404> wm4, im just describing how many integral foss projects work
[22:48:53 CEST] <Daemon404> <_<
[22:48:57 CEST] <BBB> nevcairiel: need more speed first :)
[22:49:16 CEST] <kurosu> need money first, actually ;)
[22:49:31 CEST] <durandal_1707> :)
[22:49:49 CEST] <kurosu> but that's an impressive result for a single man
[22:50:11 CEST] <nevcairiel> he did use "we", but i dont know who else that is
[22:50:11 CEST] <Daemon404> kurosu, consider that x264 was originally only 1-2 guys at a given time
[22:50:20 CEST] <Daemon404> al lthe 'big' things were largely 1 of the 2
[22:51:17 CEST] <kurosu> Daemon404, comparing people that breathed h264 for that time, to a guy with a family life and kids ? :D
[22:51:27 CEST] <Daemon404> lol
[22:51:28 CEST] <Daemon404> true
[22:51:47 CEST] <kurosu> not something I could achieve
[22:51:58 CEST] <kurosu> hence the "impressive"
[22:52:29 CEST] <Daemon404> prunetree tried it with hevc but got demotivated rather fast
[22:52:34 CEST] <Daemon404> prunedtree*
[22:52:49 CEST] <Daemon404> also because he got a busy job ;p
[22:52:56 CEST] <BBB> nevcairiel: and hevc & so, Im trying to target clients not as an instead of hevc, but as an instead of h264
[22:53:15 CEST] <BBB> nevcairiel: if theyve already chosen hevc and are happy with it, I dont think Ill convince them otherwise. ever. Im realistic about that
[22:53:27 CEST] <nevcairiel> well sure, but they would consider hevc as an alternative to "instead of h264", so its still a competition, no?
[22:53:29 CEST] <Daemon404> BBB, it cant hurt to try
[22:53:38 CEST] <Daemon404> but imo the reasons to not use hevc are not technical
[22:53:41 CEST] <nevcairiel> maybe not for switching from hevc to vp9
[22:53:42 CEST] <Daemon404> so BBB has kind of a point
[22:53:43 CEST] <BBB> true
[22:53:49 CEST] <nevcairiel> but for making the decision between hevc and vp9
[22:54:03 CEST] <Daemon404> fun fact
[22:54:03 CEST] <JEEB> yeah, the whole HEVC debacle is just so bad at the moment
[22:54:10 CEST] <Daemon404> some hw box player things ONLY support vp9 for 4k
[22:54:12 CEST] <Daemon404> no hevc
[22:54:19 CEST] <nevcairiel> sounds like an odd box
[22:54:24 CEST] <Daemon404> yep
[22:54:25 CEST] <Daemon404> roku!
[22:54:32 CEST] <nevcairiel> rokus are terrible either way
[22:54:34 CEST] <JEEB> probably a software limitation?
[22:54:39 CEST] <Daemon404> i dunno
[22:54:44 CEST] <nevcairiel> their media support is abyssmal
[22:54:46 CEST] <BBB> nevcairiel: I think hevc comparisons make little sense at 360p anyway, people would directly shout at me NOT 4k!!! FAKE!!!
[22:54:48 CEST] <Daemon404> they explicitly do not allow 4k h264
[22:54:50 CEST] <Daemon404> probably hw limit
[22:55:02 CEST] <BBB> nevcairiel: so lets get speed first, so 4k is realistic, and then Ill do 4k comparisons between h264/hevc/me
[22:55:15 CEST] <Daemon404> BBB, my issue is usually that all comparisons are at low bitrates which i dont care about
[22:55:17 CEST] <nevcairiel> speed is always nice
[22:55:20 CEST] <Daemon404> it care about higher bitrates
[22:55:24 CEST] <Daemon404> that can keep grain
[22:55:25 CEST] <Daemon404> and such
[22:55:38 CEST] <Daemon404> or not having to boost bitrate on trouble encodes for clients
[22:55:47 CEST] <Daemon404> who have style-grain and strobes
[22:55:48 CEST] <Daemon404> and such
[22:55:51 CEST] <JEEB> well UHD AVC being a software limitation wouldn't surprise me. and it wouldn't surprise me to just deliver the hardware without the HEVC support enabled in drivers/middleware
[22:55:54 CEST] <nevcairiel> arent your work encodes generally bitrate limited because streaming?
[22:56:04 CEST] <JEEB> just to work around the mess that is HEVC licensing atm
[22:56:11 CEST] <Daemon404> nevcairiel, if you bitarte spikes are kept under control
[22:56:21 CEST] <Daemon404> but if you have enough bw we will feed you a nice file
[22:56:27 CEST] <durandal_1707> how much you guys write code for living?
[22:56:36 CEST] <Daemon404> all day every day?
[22:56:41 CEST] <Daemon404> inclduing weekends?
[22:56:44 CEST] <nevcairiel> same
[22:56:48 CEST] <nevcairiel> unless i have a gaming day
[22:56:54 CEST] <Daemon404> ah true
[22:56:58 CEST] <Daemon404> sometimes i game al lsunday
[22:57:33 CEST] <wm4> I'm glad when I can write code, instead of "other" things
[22:57:55 CEST] Action: Daemon404 forces wm4 to merge at gunpoint
[22:58:05 CEST] <durandal_1707> in lines not time ;)
[22:58:14 CEST] <nevcairiel> when i have an appropriate topic i even get to w ork on ffmpeg or lav code for work, but right now i have to deal with opengl mess again
[22:58:35 CEST] <nevcairiel> (with the main problem being that i know shit about opengl)
[22:58:52 CEST] <wm4> video rendering?
[22:59:02 CEST] <kierank> durandal_1707: used to but now I look at spreadsheets and answer the phone all day :(
[22:59:21 CEST] <nevcairiel> i did video rendering last year, that worked after a bit, right now i'm doing a 10ft interface
[22:59:23 CEST] <Daemon404> RIP kierank
[22:59:25 CEST] <Daemon404> he will be missed
[22:59:34 CEST] <Daemon404> he died eating 0-calorie noodles and using excel.
[22:59:48 CEST] <kierank> 0 calorie noodles was a long time ago
[22:59:48 CEST] <wm4> nevcairiel: eh, with opengl?
[22:59:50 CEST] <JEEB> better than SAP
[22:59:54 CEST] <kierank> can't do that any more with marathon training
[22:59:56 CEST] <kierank> would just die
[23:00:03 CEST] <Daemon404> well
[23:00:06 CEST] <Daemon404> that explains the bread.
[23:00:16 CEST] <nevcairiel> wm4: of course
[23:00:22 CEST] <wm4> nevcairiel: that seems painful and inappropriate, kind of like writing a FPS game with raw GL
[23:00:25 CEST] <kierank> would just die
[23:00:27 CEST] <kierank> bah
[23:00:31 CEST] <kierank> fucking keyboard
[23:01:05 CEST] <nevcairiel> wm4: we have one with directx and its responsive and snappy, but muh crossplatform 
[23:01:22 CEST] <nevcairiel> i looked into some rendering engines or such, but they are all super convoluted for a interface only
[23:01:31 CEST] <wm4> (that's awfully low level)
[23:02:07 CEST] <nevcairiel> indeed, but i didnt find anything that would actually fit the use-case
[23:02:57 CEST] <atomnuker> I did something like that once, only used libsdl (to load ogl and open a window) and libfreetype to write a GUI
[23:03:29 CEST] <atomnuker> shaders and fontconfig were a big pain
[23:03:39 CEST] <nevcairiel> we already have font stuff etc all ready
[23:04:17 CEST] <nevcairiel> its just the actual opengl rendering thats missing, and i'm still cataloging what kind of elements and effects i really need
[23:04:37 CEST] <JEEB> I kind of wanted to buy a sony tv with android for my mpv masochism, but then I noticed that those damn UHD screens only support 1080p android rendering :<
[23:04:44 CEST] <JEEB> or at least that's what their docs hint at
[23:04:48 CEST] <wm4> atomnuker: I bet that doesn't handle non-western languages well
[23:06:06 CEST] <nevcairiel> in any case, i dont mind, its kinda fun to learn opengl along the way, even more so when making sure to use opengl3 stuff and not the deprecated stuff from 2 (even though the 2 stuff looks simpler in many ways =P)
[23:09:04 CEST] <atomnuker> wm4: well, I never tried non ascii, just did and I didn't expect it to segfault right away
[23:09:44 CEST] <atomnuker> wait, I did some weird LUT glyph storage, that might be why
[23:09:56 CEST] <atomnuker> oh well
[23:10:45 CEST] <Mavrik> JEEB, it's true
[23:10:59 CEST] <Mavrik> JEEB, also the SoC in those Sonys is so terrible they don't render that UI at 60fps
[23:11:09 CEST] <Mavrik> Even the cheapass Nexus Player performs significantly better.
[23:11:36 CEST] <JEEB> fuck that
[23:11:50 CEST] <nevcairiel> i never bought a TV for its UI features
[23:11:56 CEST] <nevcairiel> i just want a good display panel =P
[23:12:10 CEST] <JEEB> yes, but it would have also been interesting to get mpv on the TV itself
[23:13:09 CEST] <Mavrik> Does MPV support MediaCodec?
[23:13:24 CEST] <JEEB> yes, I made a wrapper like the rpi thing
[23:13:49 CEST] <JEEB> https://github.com/mpv-player/mpv/pull/2993
[23:14:17 CEST] <Daemon404> [22:11] <@nevcairiel> i never bought a TV for its UI features <-- has anyone ever?
[23:14:25 CEST] <nevcairiel> i'm sure some do
[23:15:01 CEST] <wm4> Mavrik: only with read-back
[23:15:11 CEST] <JEEB> which seems to be fast enough for most purposes
[23:15:20 CEST] <Mavrik> Yeah, was wondering if it could carry 4K
[23:15:58 CEST] <JEEB> haven't gotten to testing because of lack of content and mobile screens
[23:16:32 CEST] <JEEB> https://github.com/mpv-android/mpv-android but this is where the masochism is produced if you want to test
[23:17:40 CEST] <Mavrik> Hmm, don't currently have any of Sonys on hand :/
[23:18:22 CEST] <nevcairiel> i have a sony tv, but its older without android
[23:21:19 CEST] <JEEB> they just released a new set of models with "HDR", probably going to poke a store and test or something
[23:22:19 CEST] <nevcairiel> i've been pondering getting a UHD TV, but this years models still seem to be "too early"
[23:22:23 CEST] <nevcairiel> although much better then last years
[23:22:46 CEST] <Mavrik> Yeah, not until UHD content shows up in decent numbers.
[23:23:07 CEST] <Mavrik> And people stop having silly compatibility issues with receivers / HDMI / new DTS or whatnot
[23:27:46 CEST] <TD-Linux> oh don't worry they thought of that already, and added propagation time checks and projector brightness limits
[23:29:14 CEST] <Mavrik> :P
[23:29:32 CEST] <Mavrik> DRM for their DRM and self-destructing BRs standard yet?
[00:00:00 CEST] --- Tue May 10 2016