Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
April 2016
- 1 participants
- 60 discussions
[00:14:26 CEST] <cone-248> ffmpeg 03Bryan Huh 07master:949444348b75: avformat/dump: Fix sign bug in reported "start" time
[00:51:00 CEST] <cone-248> ffmpeg 03Jan Sebechlebsky 07master:2ea5ab6fc6b1: avformat/tee: Refactor close_slaves function in tee muxer
[01:38:41 CEST] <furkan> close
[01:38:48 CEST] <furkan> oops
[02:24:56 CEST] <cone-248> ffmpeg 03James Almer 07master:868bce48f6d8: avformat/framehash: add sidedata checksum
[02:24:57 CEST] <cone-248> ffmpeg 03James Almer 07master:0efafc584903: avformat/framehash: enable new output
[03:58:48 CEST] <rcombs> Daemon405: 6f69f7a8b breaks automatic bitstream filtering when the bsf reads input extradata (though it works fine when it only writes it); thoughts on this patch to fix? https://gist.github.com/cc357b39e5dad4eb7cb45e987736185e
[04:32:29 CEST] <michaelni> rcombs, can you add a fate test for this once its fixed ?
[04:40:50 CEST] <rcombs> probably
[04:41:46 CEST] <rcombs> one for mp4toannexb and one for adtstoasc, I guess
[04:49:26 CEST] <michaelni> k, if theres something to upload to fate-samples, ping me
[05:00:32 CEST] <rcombs> michaelni: nah, it'll probably just be remuxing existing h264 and aac samples
[06:31:47 CEST] <jamrial> rcombs: the size checks seem superfluous. av_malloc already does them
[06:34:25 CEST] <rcombs> jamrial: I was copying behavior from ff_alloc_extradata, which returns EINVAL in that case, but if you think it's unnecessary I'm not attached to it
[06:38:27 CEST] <jamrial> ah, if you want to signal einval then yeah, keep them
[06:38:36 CEST] Action: rcombs shrugs
[06:38:39 CEST] <rcombs> doesn't hurt either way
[10:47:42 CEST] <ubitux> Daemon405: re: c849ed8b2fa2e3d6d4464c652b403fe4a0b9746e there is another ref in that file
[11:49:27 CEST] <kierank> michaelni: why are you sending emails saying my student has no mentor
[12:19:12 CEST] <durandal_1707> michaelni: one of your changes broke bmp parser, please fix it
[12:19:33 CEST] <durandal_1707> last two commits to file
[12:21:38 CEST] <michaelni> durandal_1707, how can i reproduce this ?
[12:22:47 CEST] <durandal_1707> michaelni: see ticket #5438
[12:24:26 CEST] <durandal_1707> basicall supporting bmps with no size of file is fruitless
[12:25:27 CEST] <michaelni> kierank, because mentoring means doing a shitload of work and noone seems doing that work
[12:25:48 CEST] <kierank> well you are wrong
[12:27:45 CEST] <michaelni> none of the students patches have any replies or reviews, if that doesnt mean "noone seems doing the work" then i dont know what does
[12:28:04 CEST] <kierank> that's because it's code I wrote...
[12:28:15 CEST] <kierank> and the student is working on getting it into mainline
[12:28:23 CEST] <kierank> carl said student didn't send patches, student then sent patches
[12:28:31 CEST] <michaelni> ahh, ok but still
[12:28:35 CEST] <michaelni> someone has to review it
[12:28:44 CEST] <kierank> yes, get carl to do it
[12:28:47 CEST] <kierank> he was the one complaining
[12:28:53 CEST] <michaelni> its not carls job
[12:29:09 CEST] <kierank> if he complains about lack of patches he should damn well review them
[12:29:29 CEST] <michaelni> its his job as admin to complain if something is missing
[12:31:42 CEST] <kierank> to be more precise patch 1 is mine/Stefano/Andreas and 2/3 is by the student
[12:31:58 CEST] <kierank> but they are dependent so someone needs to review 1
[12:36:39 CEST] <michaelni> so we need someone to review the patches over the course of gsoc (that is now till end) for this project to be possible
[12:36:54 CEST] <kierank> oh for god sake
[12:37:00 CEST] <kierank> how hard is it for you to understand
[12:37:12 CEST] <kierank> the first patch in the patchset is my patch so I can't review it
[12:37:17 CEST] <kierank> the next two are dependent
[12:37:28 CEST] <kierank> so I am waiting for a review of 1 so that I can review 2/3
[12:37:43 CEST] <kierank> the rest of the patches for gsoc I will review as mentor
[12:37:56 CEST] <kierank> ALSO, since it's a test suite program like fate these patches won't necessarily go into mainline
[12:38:00 CEST] <kierank> are you happy now?
[12:39:18 CEST] <michaelni> can you find someone to review patches that you cant review ? (its your job as mentor IMO)
[12:39:46 CEST] <kierank> michaelni: speak for yourself
[12:39:54 CEST] <kierank> and the number of times you push patches to git without review
[12:40:20 CEST] <wm4> lol.
[13:41:37 CEST] <fritsch> since ffmpeg 3.x we continuingly run into segfaults, when convertion from yuv to rgba ... which is only workarounded by aligning the buffer's start adress to 16 byte
[13:41:56 CEST] <nevcairiel> its generally wise to do that anyway
[13:42:03 CEST] <nevcairiel> because the alternative is using extremely slow conversion
[13:42:07 CEST] <fritsch> yeah, we have a home grown kodi since years :-)
[13:42:12 CEST] <fritsch> and supply sometimes external buffers
[13:42:18 CEST] <fritsch> but three more places to go
[13:42:19 CEST] <fritsch> and fine
[13:42:25 CEST] <fritsch> though, it's kind of a regression
[13:42:48 CEST] <durandal_1707> what arch?
[13:42:52 CEST] <fritsch> arm
[13:43:03 CEST] <fritsch> https://github.com/fritsch/xbmc/commit/a7c9359722aa039132d652379237a9c5522a… <- last one
[13:43:13 CEST] <nevcairiel> probably some new arm optimization that doesnt have checks
[13:43:20 CEST] <durandal_1707> there where patches for it?
[13:43:24 CEST] <fritsch> jep
[13:43:32 CEST] <fritsch> my colleague tracked it down to a certain commit
[13:43:34 CEST] <fritsch> one moment, please
[13:43:54 CEST] <mateo`_> It's probably mine I guess
[13:44:04 CEST] <fritsch> will ping you some time later ... oral exam and the student is appearing :-)
[13:44:09 CEST] <fritsch> mateo`_: yeah, i think so
[13:45:39 CEST] <mateo`_> fritsch: if you can give me your use-case, ie: using sws scale directly or whatever, i'll make a patch
[13:46:26 CEST] <fritsch> yeah - i tried to reproduce from command line but could not
[13:46:34 CEST] <fritsch> most likely as ffmpeg allocates its buffers correctly
[13:46:39 CEST] <fritsch> one use case you see in the above commit
[13:46:52 CEST] <fritsch> http://xbmclogs.com/p2bizm4cv <- basically
[13:46:53 CEST] <fritsch> last line
[13:47:03 CEST] <fritsch> if you get this warning it will crash
[13:47:13 CEST] <fritsch> shortly afk - thx much
[13:48:07 CEST] <mateo`_> yeah because it's an unscaled conversion and it beleives there is no generic accelerated path if i remember correctly
[13:51:41 CEST] <ubitux> aren't image buffers fed to ffmpeg always supposed to be aligned?
[13:51:55 CEST] <ubitux> or basically allocated with av alloc* funcs?
[13:52:01 CEST] <wbs> not for swscale at least
[13:53:23 CEST] <nevcairiel> i think i've had x86 scaling also crash before without alignment
[13:54:11 CEST] <wbs> it has occasionally been broken, but mostly should work. would probably good to have tests for it (or declare clearly that it isn't supported)
[13:54:24 CEST] <wbs> at least for input it really should be supported though
[13:55:20 CEST] <mateo`_> so we need a check before on the src alignment before it reaches the accelerated path ...
[13:55:33 CEST] <mateo`_> -before
[13:57:55 CEST] <ubitux> i see all kind of mova in x86 code
[13:58:15 CEST] <ubitux> but maybe that's for other stuff
[13:58:21 CEST] <nevcairiel> if he gets that particular warning its using C code though
[13:58:49 CEST] <nevcairiel> maybe the C does evil things that crash on arm due to type alignment constraints?
[13:58:50 CEST] <ubitux> nevcairiel: no, that warning is broken
[13:58:52 CEST] <ubitux> :D
[13:58:58 CEST] <Daemon405> ubitux, feel free to remove that ref
[13:59:01 CEST] <nevcairiel> lol
[13:59:24 CEST] <ubitux> nevcairiel: the warning is raised if it doesn't find the optimisation in the "first pass of setting simd functions"
[13:59:32 CEST] <ubitux> or sth along these lines :p
[13:59:46 CEST] <ubitux> anyway, yuv420p to rgb* is an unscaled accelerated path
[14:00:02 CEST] <ubitux> on arm & aarch64 at least
[14:00:25 CEST] <ubitux> i'm not sure how we're supposed to deal with unaligned buffers here
[14:02:58 CEST] <ubitux> fritsch: can you show a backtrace and registers?
[14:03:24 CEST] <Daemon404> wm4, next merges are the hw stfuf youve been waiting for i think
[14:03:39 CEST] <Daemon404> from jkqxz
[14:04:05 CEST] <wm4> dunno
[14:04:12 CEST] <Daemon404> well, some of them
[14:04:52 CEST] <wm4> ah, hwcontext shit
[14:05:48 CEST] <wm4> and another annoying deprecation
[14:06:18 CEST] <wm4> and ahead is the new bitstream API
[14:09:11 CEST] <Daemon404> yes
[14:09:17 CEST] <Daemon404> i want yo get both in today
[14:09:19 CEST] <Daemon404> if possible
[14:10:01 CEST] <nevcairiel> bsf api may break autobsf to some degree
[14:10:23 CEST] <nevcairiel> not sure if its fully compatible with our hacks to the extradata
[14:11:09 CEST] <nevcairiel> it would also be nice to finally decide on one way to update extradata in bsfs, i've at least seen two in post-bsf-rewrite in libav
[14:11:48 CEST] <nevcairiel> (sidedata and updating output codecpar)
[14:12:18 CEST] <wm4> sounds like a pain
[14:12:35 CEST] <wm4> is sidedata for mid-stream updates or so?
[14:12:49 CEST] <nevcairiel> both could be midstream =p
[14:13:18 CEST] <nevcairiel> personally i would probably just make the filters all emit sidedata, and then catch that sidedata in generic bsf code and update codecpar from that
[14:13:22 CEST] <nevcairiel> but what do i know
[14:25:20 CEST] <jkqxz> Daemon404: Do poke me if there is anything annoying in those merges; I'm happy to deal with it myself.
[14:25:57 CEST] <Daemon404> jkqxz, sure.
[14:28:50 CEST] <jkqxz> (I think the first set should be mostly fine, but the (avconv|ffmpeg)_vaapi.c one a bit later might be nasty.)
[14:29:04 CEST] <Daemon404> :)
[14:32:03 CEST] <cone-945> ffmpeg 03Luca Barbato 07master:1098f5c0495c: svq3: Use a separate buffer for decoding the slices
[14:32:03 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:7af788aa6257: Merge commit '1098f5c0495c61a98d4ff6b8e24c17974d4bace5'
[14:38:33 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:b1f01e85a92d: lavu: add a way to query hwcontext frame constraints
[14:38:34 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:afccfaf26ac8: Merge commit 'b1f01e85a92d401a9b29c79f23db36b7685e8c09'
[14:45:22 CEST] <fritsch> ubitux: sadly not - working on it. It only happens on user's systems - not on mine
[14:46:03 CEST] <fritsch> ubitux: https://github.com/FFmpeg/FFmpeg/commit/b32a42295ad7b254f9662082d799c0aae20… <- the user affected pointed on this commit, but as I did not bisect it myself ... i cannot verify
[14:46:07 CEST] <fritsch> aligning the buffers fixed the issues
[14:46:17 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:d264c720f7b7: lavu: deprecate AV_PIX_FMT_VAAPI_*, replace with AV_PIX_FMT_VAAPI
[14:46:18 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:eb2da769bddf: Merge commit 'd264c720f7b74286840719e506daba39f83b438b'
[14:47:19 CEST] <fritsch> ubitux: the fix (to use aligned buffers fixed the issue) user reported back: http://forum.kodi.tv/showthread.php?tid=269232&pid=2310549#pid2310549 (sorry, just a user ... they speakk as l33t 4s th3y l1k3)
[14:48:36 CEST] <ubitux> fritsch: i know that's not a valid answer to the issue, but is it a problem to have these buffers aligned?
[14:48:46 CEST] <fritsch> no, not at all
[14:48:47 CEST] <fritsch> :-)
[14:48:50 CEST] <fritsch> i will align them anyways
[14:49:16 CEST] <fritsch> now I saw the issue ... but it's most likely regression as one needs to make really sure that users don't supply their own bufers
[14:49:28 CEST] <fritsch> which are 16 aligned concerning the stride, but not concerning memory adress
[14:53:53 CEST] <wm4> why are you using libswscale for RGB conversion at all?
[14:56:02 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:551c6775abb5: lavu: VAAPI hwcontext implementation
[14:56:03 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:28abb216cbd5: Merge commit '551c6775abb5e0ad34c26d7e23bc6fbbe8ccc9d4'
[15:01:11 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:07a844f32ebb: lavfi: generic hardware surface upload and download filters
[15:01:12 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:8688d3af39e8: Merge commit '07a844f32ebb78503981df017fa3ebfedb75fe1c'
[15:02:04 CEST] <cone-945> ffmpeg 03Luca Barbato 07master:9765549f551f: mpegts: Forward the errors on mpeg4 objects parsing
[15:02:05 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:0520d573db71: Merge commit '9765549f551ff40869aee1a6492b6a976c86cfe9'
[15:02:39 CEST] <cone-945> ffmpeg 03Andreas Cadhalpun 07master:a2d1922bde8d: takdec: ensure chan2 is a valid channel index
[15:02:40 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:e1a8f7818cc8: Merge commit 'a2d1922bde8db2cdac95051918fe81ae18c0376b'
[15:02:51 CEST] <Daemon404> nevcairiel, next commit is "lavc: add a new bitstream filtering API"
[15:02:57 CEST] <Daemon404> i assume this wont be "simple"?
[15:18:32 CEST] <fritsch> wm4_: why not?
[15:18:40 CEST] <fritsch> it's easy to supply our given buffer
[15:18:43 CEST] <wm4_> isn't it slow
[15:18:48 CEST] <fritsch> nope
[15:18:53 CEST] <fritsch> context setup perhaps
[15:18:56 CEST] <wm4_> on what shit devices does this run?
[15:19:00 CEST] <fritsch> lol
[15:19:04 CEST] <fritsch> on the xbox 1 :-)
[15:19:06 CEST] <wm4_> (and why are they fast enough for this)
[15:19:12 CEST] <wm4_> lol indeed
[15:19:23 CEST] <fritsch> pi, arm devices and so on
[15:19:38 CEST] <fritsch> and our texturepacker needs RGBA
[15:19:44 CEST] <wm4_> the rpi can output RGB just fine
[15:19:50 CEST] <wm4_> s/RGB/YUV
[15:19:52 CEST] <fritsch> it's not about outputting
[15:20:04 CEST] <fritsch> see for example: https://github.com/xbmc/xbmc/pull/9623/commits/a7c9359722aa039132d652379237…
[15:20:11 CEST] <fritsch> it's used to extract a thumb image
[15:20:15 CEST] <fritsch> and store it as texture
[15:20:25 CEST] <ubitux> wm4_: hey sws is fast now for this!
[15:20:26 CEST] <wm4_> ah, that makes sense
[15:20:54 CEST] <fritsch> i think I hit all the sws_scales in our code ... and when interacting with sws_scale memory adress should be 16 aligned now
[15:20:57 CEST] <wm4_> if you want a total freak usage of libswscale, mpv uses it to render subtitles to YUV surfaces (only used in encoding more or for good old Xv)
[15:23:13 CEST] <fritsch> as we depend on sws_scale in those methods anyways ... we should use av_malloc
[15:23:21 CEST] <fritsch> right away ... to be "safe" for the future
[15:23:39 CEST] <fritsch> at least when we allocate in the classes where sws_scale happens
[15:24:17 CEST] <fritsch> that was for the wrong channel
[15:24:37 CEST] <wm4_> still good advice though
[15:25:06 CEST] <wm4_> I'd just use AVFrame everywhere
[15:25:20 CEST] <wm4_> and maybe I should resend my patch that adds a AVFrame libswscale API
[15:29:30 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07master:8e26bdd59bf5: avcodec/bmp_parser: Ensure remaining_size is not too small in startcode packet crossing corner case
[15:29:33 CEST] <michaelni> durandal_170, fixed the bmp case
[15:42:00 CEST] <Daemon404> nevcairiel, feel liek helping me out with the bsf stuff at some point?
[15:48:11 CEST] <durandal_170> merbzt: I stare at decompiler output and couldnt find nothing wrong with our decoder
[15:55:14 CEST] <durandal_170> except that lpc filter is missing
[16:01:22 CEST] <nevcairiel> Daemon404: i have like an hour now, then nothing until saturday or so
[16:02:17 CEST] <Daemon404> urg
[16:02:39 CEST] <Daemon404> you seem to understand the problem space a lot better than me though
[16:03:35 CEST] <nevcairiel> going to the cinema tonight, and got some appointments tomorrow
[16:03:41 CEST] <nevcairiel> but that patch shouldnt be that bad
[16:03:49 CEST] <nevcairiel> just need to update the BSFs libav doesnt have
[16:03:52 CEST] <Daemon404> i wasnt sure how to handle some extradata stuff we have but they dont
[16:03:56 CEST] <Daemon404> in shared bsfs
[16:04:00 CEST] <nevcairiel> like what
[16:04:24 CEST] <Daemon404> aac_adtstoasc_bsf.c shows one
[16:04:37 CEST] <nevcairiel> dont they have that
[16:05:20 CEST] <nevcairiel> like I ranted on earlier, for some reason libav shows two variations on handling extradata, either they update the outgoing codecpar directly, or they send extradata changed sidedata
[16:05:37 CEST] <wm4_> what did elenril say to this
[16:05:43 CEST] <nevcairiel> i forgot to ask, i think
[16:06:01 CEST] <Daemon404> ah... right...
[16:06:30 CEST] <Daemon404> do you want me to skip merging the avconv bsf conversion
[16:06:33 CEST] <nevcairiel> for some reason the aac bsf doesnt even allow the extradat to change beyond the first frame
[16:06:35 CEST] <Daemon404> because i dont think i CAN merge it anyway
[16:06:43 CEST] <Daemon404> since we havent converted to codecpar in ffmpeg.c
[16:06:46 CEST] <nevcairiel> so changing codecpar is probably the better approach
[16:06:53 CEST] <nevcairiel> and works with autobsf better
[16:07:02 CEST] <Daemon404> lemme guess: no autobsf fate tests
[16:07:06 CEST] <nevcairiel> so for the moment i would skip the sidedata approach
[16:07:30 CEST] <Daemon404> heh
[16:07:48 CEST] <nevcairiel> what other bsfs do we have that change extradata
[16:08:08 CEST] <nevcairiel> mp4toannexb bsfs dont support changing extradata mid-stream, since mp4-style doesnt allow that
[16:08:39 CEST] <Daemon404> libavcodec/remove_extradata_bsf.c ?
[16:08:44 CEST] <Daemon404> (lol why does this exist)
[16:08:52 CEST] <nevcairiel> clearly thats a onetime change to extradata as well
[16:08:53 CEST] <nevcairiel> and no idea
[16:09:29 CEST] <Daemon404> my big problem is that we dont have anything that tests bsfs well in fate
[16:09:33 CEST] <Daemon404> autobsf, concat, etc
[16:09:35 CEST] <Daemon404> nothin'.
[16:10:48 CEST] <Daemon404> nevcairiel, ill try and merge today and maybe we can attempt to start to tackle ffmpeg.c conversion sometime soon
[16:10:51 CEST] <Daemon404> keyword: attemot
[16:10:54 CEST] <Daemon404> s/o/p/
[16:11:18 CEST] <nevcairiel> sure
[16:12:36 CEST] <Daemon404> btw
[16:12:50 CEST] <Daemon404> weve been runnign post-codecpar ffmpeg for a subset of transcodes at work
[16:12:57 CEST] <Daemon404> nothing really of note has failed or changed
[16:12:57 CEST] <Daemon404> afaik
[16:13:02 CEST] <Daemon404> seems pretty stable.
[16:14:06 CEST] <nevcairiel> maybe we should add a aac adts -> mkv including autobsf test to fate if its really not tested
[16:14:13 CEST] <nevcairiel> its the prime example what autobsf was supposed to fix
[16:14:38 CEST] <Compn> durandal_170 : so you found truemotion2rt sample ? :)
[16:15:23 CEST] <Daemon404> nevcairiel, i was also planning to add a chapters/ffprobe test
[16:15:30 CEST] <Daemon404> since fate failed to catch that chapters regression yesterday
[16:15:43 CEST] <durandal_170> Compn: lol no, piotr created them...
[16:18:40 CEST] <Daemon404> libavcodec/bsf.h [copied from libavcodec/chomp_bsf.c with 53% similarity]
[16:18:42 CEST] <Daemon404> lol git...
[16:18:42 CEST] <Compn> best solution :)
[16:19:12 CEST] <nevcairiel> Daemon404: copyright header, i assure you
[16:19:12 CEST] <Compn> durandal_170 : what codecs are you working on next? just curious :)
[16:19:53 CEST] <Daemon404> nevcairiel, yep
[16:22:40 CEST] <durandal_170> Compn: optimfrog
[16:23:41 CEST] <wm4_> fritsch: how terrible is amlogic?
[16:24:10 CEST] <fritsch> don't ask :-(
[16:24:16 CEST] <fritsch> it's a "streaming" decoder
[16:24:26 CEST] <fritsch> made for decode + render by their own
[16:24:32 CEST] <fritsch> so the moment you don't care about audio
[16:24:39 CEST] <fritsch> you don't care about dropping / skipping
[16:24:42 CEST] <fritsch> don't render subtitles
[16:24:44 CEST] <fritsch> it's nice :-)
[16:25:05 CEST] <fritsch> the moment you want to exactly know when the pic appears and do proper a/v sync
[16:25:08 CEST] <fritsch> it sucks
[16:25:25 CEST] <fritsch> in kodi it was used for years with a global "player" clock
[16:25:43 CEST] <fritsch> and it just told the player: this pic will be presented one frame in the future
[16:25:47 CEST] <fritsch> no matter how late it was
[16:25:52 CEST] <fritsch> we have big problems with it currently
[16:25:57 CEST] <fritsch> as maintainer is gone
[16:26:14 CEST] <wm4_> maintainer gone? on the kodi or the amlogic side?
[16:26:19 CEST] <fritsch> we experimented with the v4l api
[16:26:22 CEST] <fritsch> to get the frames back
[16:26:27 CEST] <fritsch> yeah for kodi
[16:27:50 CEST] <wm4_> terrible
[16:27:51 CEST] <fritsch> wm4_: you need to make a video player around it?
[16:28:02 CEST] <wm4_> some are asking
[16:28:08 CEST] <fritsch> if yes, check kodi's AMLogic.cpp and VideoCodecAML.cpp
[16:28:29 CEST] <fritsch> i can also give you the contact of the really cool first author
[16:28:39 CEST] <fritsch> in kodi it is used "bypass" style
[16:28:47 CEST] <fritsch> you set a chain via sysfs / procfs
[16:28:56 CEST] <wm4_> wat
[16:28:58 CEST] <fritsch> and decoded stuff directly hits the output
[16:29:10 CEST] <fritsch> this thingy is not ment like:
[16:29:20 CEST] <fritsch> frame = aml->decode(data);
[16:29:23 CEST] <fritsch> display(frame);
[16:29:30 CEST] <Daemon404> do {
[16:29:30 CEST] <Daemon404> bsf->next = first_bitstream_filter;
[16:29:30 CEST] <Daemon404> } while(bsf->next != avpriv_atomic_ptr_cas((void * volatile *)&first_bitstream_filter, bsf->next, bsf));
[16:29:35 CEST] <Daemon404> well this is.... something
[16:29:39 CEST] <Daemon404> (from ffmpeg)
[16:29:45 CEST] <wm4_> Daemon404: yeah, duplicated all over the place
[16:29:54 CEST] <wm4_> (for other component lists)
[16:30:05 CEST] <wm4_> this code dies now, doesn't it
[16:30:22 CEST] <Daemon404> at least where im looking, it dies
[16:30:26 CEST] <Daemon404> cant say for teh copypasted bits
[16:31:00 CEST] <wm4_> fritsch: ARM/Linux stuff is so sad
[16:33:15 CEST] <fritsch> yeah - you can be our AMLCodec maintainer if you want :-)
[16:34:32 CEST] <wm4_> fritsch: so the v4l API didn't work?
[16:34:47 CEST] <fritsch> it worked
[16:34:50 CEST] <fritsch> but slow as hell
[16:35:00 CEST] <fritsch> there is an open PR on github
[16:35:04 CEST] <fritsch> about it
[16:35:48 CEST] <wm4_> and apparently the hw works fine on android
[16:36:38 CEST] <fritsch> yes
[16:36:53 CEST] <fritsch> wait it was not v4l at the end
[16:36:56 CEST] <fritsch> let me recheck
[16:37:28 CEST] <fritsch> it was the ION driver
[16:38:24 CEST] <wm4_> uh what's ION?
[16:38:33 CEST] <fritsch> https://github.com/xbmc/xbmc/pull/9432/commits/194ba453080db5cb0762ff7f0910…
[16:38:38 CEST] <fritsch> that's what they use in android
[16:38:44 CEST] <fritsch> to use amlogic via mediacodec
[16:38:49 CEST] <fritsch> wrapper to wrapper to wrapper
[16:38:52 CEST] <fritsch> wrapped up nicely
[16:42:38 CEST] <Daemon404> nevcairiel, the annexb filters differ annoyingly from libav
[16:43:16 CEST] <wm4_> fritsch: blergh wtf
[16:43:51 CEST] <Daemon404> libavcodec/hevc_mp4toannexb_bsf.c: Optional argument "private_spspps_buf" to avoid extradata modification.
[16:43:54 CEST] <Daemon404> so this is why
[16:43:56 CEST] <Daemon404> ugh...
[16:44:01 CEST] <Daemon404> what the hell.
[16:44:10 CEST] <Daemon404> of cours it is from nablet...
[16:44:33 CEST] <nevcairiel> we have avoptions in the new design, should at least make it a bit saner
[16:44:47 CEST] <Daemon404> nevcairiel, yeah but merging with that commit makes it far more annoying/complicated
[16:44:58 CEST] <Daemon404> is it even still needed (other than for api compat)
[16:45:09 CEST] <nevcairiel> dunno
[16:45:25 CEST] <Daemon404> as far as i concerned its a shitty hack
[16:45:35 CEST] <wm4_> is this the only place where a bsf uses the argument?
[16:46:05 CEST] <nevcairiel> its nabblet code, they have done nothing but make ffmpeg worse
[16:46:28 CEST] <Daemon404> ... ok so
[16:46:35 CEST] <Daemon404> i cant see, given this commit, how the fuck you'd actually set it
[16:46:48 CEST] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=0b8b18b4fbbd800849d538…
[16:46:52 CEST] <nevcairiel> arguments to the old bsf design was freaking insane
[16:47:52 CEST] <wm4_> av_bitstream_filter_filter(c->bsfc, avctx, "private_spspps_buf", &dummy_p, &dummy_int, NULL, 0, 0);
[16:48:04 CEST] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1defff85
[16:48:08 CEST] <Daemon404> the same crap applied to h264
[16:48:10 CEST] <wm4_> this one would parse the initial extradata
[16:48:11 CEST] <Daemon404> makign merging a big pita
[16:49:53 CEST] <Daemon404> motivation = gone
[16:50:11 CEST] <Daemon404> i dont feel like spending time makign a shit hack work
[16:50:58 CEST] <wm4_> ffmpeg development in a nutshell
[16:52:42 CEST] <Daemon404> i think i made hevc work, but... meh
[16:53:08 CEST] <wm4_> the problem is fixing the old API emulation, right?
[16:54:49 CEST] <Daemon404> wm4_, i have to be careful in writing to teh correct buffer too
[16:55:00 CEST] <Daemon404> also can avoption even take a pointer
[16:55:35 CEST] <wm4_> pointer to what?
[16:55:50 CEST] <Daemon404> the spspps buf.
[16:56:14 CEST] <Daemon404> see: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=0b8b18b4fbbd800849d538…
[16:56:37 CEST] <Daemon404> oh, wait those are not passed
[16:56:38 CEST] <Daemon404> bleh
[16:56:41 CEST] <Daemon404> i just dont want to deal with this
[17:02:03 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/commit/037bdc6bf0ffb2c6b1350200637926df6…
[17:02:09 CEST] <Daemon404> nevcairiel / wm4_ - i left off here.
[17:02:15 CEST] <Daemon404> no motivation to deal with nablet's crap
[17:06:11 CEST] <nevcairiel> Daemon404: the aac filter uses the weird sidedata approach, which i dont think makes much sense, but it sounds like you wont finish that tonight either way, so i can work on that hopefully tomorrow morning for a bit before i have to leave again
[17:06:32 CEST] <Daemon404> nevcairiel, i was planning on working on it after making stuff... work/build
[17:06:40 CEST] <Daemon404> but meh
[17:07:17 CEST] <Daemon404> id like someone to poke h264/hevc, really.
[17:09:18 CEST] <nevcairiel> their hack is probably not needed anymore anyway because new bsfs have a in and out context and dont overwrite the only context they have without question
[17:09:35 CEST] <Daemon404> i know. i wanted to just remove it.
[17:09:44 CEST] <Daemon404> but i wasnt sure that was ok or not
[17:19:16 CEST] <jamrial> Daemon404: BBB said he'd convert his vp9 bsf
[17:19:26 CEST] <jamrial> and you should poke durandal_170 for dca_core
[17:19:26 CEST] <Daemon404> sure, but that was never my issue :P
[17:19:40 CEST] <jamrial> just saying :p
[17:20:00 CEST] <nevcairiel> its really trivial to convert things
[17:20:16 CEST] <nevcairiel> i would not even try to merge conversions, just do it myself
[17:40:53 CEST] <durandal_170> so, merges are still comming?
[17:41:28 CEST] <Daemon404> durandal_170, i merged like 60 commits in the last 2 days
[17:41:31 CEST] <Daemon404> have some patience
[17:41:38 CEST] <Daemon404> current WIP is merging the new bsf api
[18:02:56 CEST] <durandal_170> someone was sloppy when doing ff_get_extradata for codecpar
[18:03:20 CEST] <durandal_170> Passing codecpar to log context
[18:03:43 CEST] <Daemon404> good thing you put in so much time to help us and review.
[18:13:06 CEST] <durandal_170> ok to push fix?
[18:15:03 CEST] <Daemon404> if it is super trivial
[18:23:15 CEST] <durandal_170> it is
[18:24:13 CEST] <durandal_170> just add AVFormatContext to ff_get_extradata
[18:30:42 CEST] <cone-626> ffmpeg 03Paul B Mahol 07master:323b8c95e410: avformat: add AVFormatContext to ff_get_extradata()
[19:03:55 CEST] <Daemon404> roflmao x32
[19:08:45 CEST] <JEEB> lol
[19:35:18 CEST] <llogan> michaelni: why did you remove yourself as a backup Outreachy admin?
[19:36:22 CEST] <Daemon404> presumably because he doesnt want to be
[19:37:44 CEST] <llogan> as the only remaining backup admin i would like to know the actual reason
[19:43:59 CEST] <michaelni> llogan, ive reverted it, so iam backup admin again too
[19:45:10 CEST] <michaelni> but iam happy to remove myself again if someone wants/prefers
[19:46:19 CEST] <llogan> michaelni: i was just curious since i did not hear anything from anyone. if you don't want to be backup that is fine with me, but you should at least let Kieran and I know.
[20:22:51 CEST] <cone-233> ffmpeg 03Paul B Mahol 07master:c9fb81ff411a: avcodec/atrac3: pass AVCodecContext to av_log if available
[20:45:21 CEST] <Daemon404> atrac lossless is a thing?
[20:48:53 CEST] <JEEB> yeah
[20:49:17 CEST] <wm4_> is that dolby trying to make money or what
[20:49:32 CEST] <Daemon404> atarc is sony
[20:49:55 CEST] <JEEB> I should poke ATRAC9 when I have the free time, since they decided to use it for PS4/Vita :V
[20:50:04 CEST] <JEEB> so much audio NIH
[20:53:37 CEST] <TD-Linux> the best part is the PS4 also ships libopus, so they actually have a better audio codec available
[20:59:02 CEST] <JEEB> lol
[20:59:07 CEST] <Daemon404> and people actually will play ps4 games
[20:59:09 CEST] <Daemon404> unlike the vita.
[21:02:00 CEST] <JEEB> yeah, although it's still somewhat alive in a single region
[22:19:51 CEST] <jamrial_> durandal_170: if you're really going to replace scalarproduct_and_madd_int16 with scalarproduct_and_madd_int32 on wmalossless instead of trying to find a way to use one or the other depending on bps, then you can remove the emms_c() after it
[22:20:17 CEST] <jamrial_> there's no need for it anymore
[22:20:52 CEST] <durandal_170> Ok
[22:33:41 CEST] <cone-182> ffmpeg 03Paul B Mahol 07master:9cd2ca9966d0: avcodec/ralf: add support for mono
[23:49:43 CEST] <mgraczyk> Hello, I have a question about adding a new channel layout to FFmpeg.
[23:50:18 CEST] <mgraczyk> I am adding Ambisonic coding support to Opus, and I would like to tell libopusenc that it should be encoding ambisonics.
[23:50:40 CEST] <mgraczyk> It looks like the channel layout structures are based around a bit vector for particular physical channels.
[23:50:55 CEST] <mgraczyk> Ambisonics do not follow such a pattern, but I believe it can be considered a channel layout.
[23:51:21 CEST] <mgraczyk> How could we go about adding ambisonics as a channel layout? Or should we pass it in as a different kind of parameter?
[23:58:13 CEST] <cone-544> ffmpeg 03James Almer 07master:c8ed93efcf4d: avformat/yop: alloc codecpar extradata only once
[00:00:00 CEST] --- Fri Apr 15 2016
1
0
[00:00:21 CEST] <fearnothing> Could not write header for output file #0 (incorrect codec parameters ?): Function not implemented
[00:00:27 CEST] <fearnothing> and
[00:00:28 CEST] <fearnothing> [matroska @ 0x9c4fa0] Subtitle codec 94213 is not supported.
[00:00:41 CEST] <fearnothing> guess that means I have to rip again as m4v
[00:01:08 CEST] <furq> paste the full output
[00:01:54 CEST] <furq> actually never mind i'm pretty sure that's mov_text
[00:02:15 CEST] <furq> ffmpeg -i src.m4v -c copy -map 0:0 -map 0:1 -map 0:2 out.mkv
[00:02:37 CEST] <fearnothing> https://bpaste.net/show/2077298c56f5
[00:02:50 CEST] <furq> yeah it is
[00:03:03 CEST] <furq> i'd have thought it would pick the subtitle stream which is actually supported, but oh well
[00:03:20 CEST] <fearnothing> now "[matroska @ 0x1d1f1e0] Tag mp4s/0x7334706d incompatible with output codec id '94208' ([0][0][0][0])"
[00:04:19 CEST] <furq> fun
[00:04:35 CEST] <furq> you'll probably have better luck just OCRing the subs or trying to find external subs which match up
[00:04:53 CEST] <fearnothing> even better than re-ripping direct to mkv?
[00:04:58 CEST] <furq> yeah definitely don't rerip
[00:05:10 CEST] <furq> get subrip or something
[00:05:24 CEST] <furq> it's fairly painless, just a bit tedious
[00:05:37 CEST] <fearnothing> subrip is a tool?
[00:05:40 CEST] <furq> yeah
[00:06:08 CEST] <fearnothing> ok, maybe I'll just finish ripping the library and then try to sort this out afterwards
[00:06:14 CEST] <fearnothing> when I can do it all in one go
[00:06:38 CEST] <fearnothing> "for F in *.m4v; do N=$(echo $F | cut -d "." -f 1); sudo ffmpeg -i "$F" -c copy "$N.mkv"; done"
[00:06:38 CEST] <furq> http://www.opensubtitles.org/en/search
[00:06:49 CEST] <furq> you might have some luck on there as well
[00:07:08 CEST] <furq> it's pretty comprehensive but a lot of the subs have timing issues due to different releases etc
[00:07:25 CEST] <fearnothing> perhaps... got about 30 movies with subtitles though
[00:07:41 CEST] <fearnothing> bit of a faff
[00:08:08 CEST] <fearnothing> I can understand why DVDs did image subtitles, but I still want to smack someone :P
[00:08:25 CEST] <furq> also you can replace N=$(echo $F | cut -d "." -f 1) with N=${F%%.*}
[00:08:50 CEST] <fearnothing> ah thank you :)
[00:09:03 CEST] <furq> you probably also want to strip the subtitles out in the conversion, so add -sn to the ffmpeg command
[00:09:22 CEST] <furq> it's weird that the dvd subtitles won't remux though
[00:09:38 CEST] <fearnothing> yeah I haven't exactly messed around with the defaults on handbrake much
[00:09:50 CEST] <furq> it's definitely supported, but maybe the weird non-standard dvd-subtitles-in-mp4 are screwing it up
[00:10:04 CEST] <fearnothing> yeah I think I will rip to mkv from now on
[00:10:38 CEST] <furq> does handbrake still default to some ridiculous x264 preset
[00:10:43 CEST] <furq> iirc it defaults to veryfast or something
[00:11:03 CEST] <fearnothing> is that the quality scale?
[00:11:22 CEST] <furq> i think it's listed under preset
[00:11:23 CEST] <furq> on the same page
[00:11:39 CEST] <fearnothing> oh, yeah it is using that
[00:12:02 CEST] <furq> fun
[00:12:08 CEST] <furq> you should change that to the slowest profile you can tolerate
[00:12:12 CEST] <furq> s/profile/preset/
[00:12:17 CEST] <fearnothing> what's the issue with that?
[00:12:27 CEST] <furq> slower presets compress better
[00:12:31 CEST] <furq> but run slower, obviously
[00:12:42 CEST] <fearnothing> is that the only difference?
[00:13:00 CEST] <fearnothing> I've not really noticed an issue with compression and I certainly don't have any issues with available space
[00:13:05 CEST] <furq> fair enough
[00:13:11 CEST] <furq> well at least it's not ultrafast, which is really bad
[00:13:18 CEST] <Mavrik> oh yeah
[00:14:05 CEST] <fearnothing> currently getting about 1GB per hour of movie
[00:14:07 CEST] <furq> as long as the CRF is set to a reasonable value, veryfast should still look ok
[00:14:22 CEST] <fearnothing> although Saving Ryan's Privates is for some odd reason 4.9GB
[00:14:48 CEST] <furq> isn't that 8 minutes long
[00:15:08 CEST] <fearnothing> 2:42
[00:15:18 CEST] <fearnothing> 2:42:00 that is
[00:15:28 CEST] <furq> oh never mind there are two films with that name
[00:15:31 CEST] <fearnothing> oh, and Seven Samurai has ended up at 5.4GB
[00:15:57 CEST] <furq> it might be worth trying those with a slower preset
[00:16:01 CEST] <iive> is there a lot of film grain in the source?
[00:16:18 CEST] <furq> and yeah if they're excessively grainy you can give the denoise filters a try
[00:16:24 CEST] <fearnothing> Seven Samurai will have
[00:16:25 CEST] <furq> handbrake has quite a good one iirc
[00:16:32 CEST] <fearnothing> SPR shouldn't
[00:16:36 CEST] <furq> nlmeans
[00:17:03 CEST] <iive> noise compresses horrible and it doesn't add useful info
[00:17:16 CEST] <fearnothing> oddly enough, Seven Samurai should be very similar to Rashomon, yet Rashomon is only 2.1GB
[00:17:42 CEST] <furq> i prefer to preserve noise in films, especially good ones
[00:18:10 CEST] <furq> maybe less so if the source is a dvd
[00:18:41 CEST] <furq> i'm not a fan of denoised blu-ray rips though
[00:18:53 CEST] <furq> even if they are 1/3 the size
[00:26:25 CEST] <zamba> is it possible to adjust a/v sync without reencoding?
[00:31:13 CEST] <explodes> Any reason a yuv420p video may be incorrectly determined to be yuv420p?
[00:31:55 CEST] <explodes> Probe buffer is 8KB, format comes back as *something* but it isn't a format supported by sws_scale -> sws_setColorspaceDetails -> isYUV
[00:32:29 CEST] <explodes> Making sure it is a supported format in the isYUV function is enforced by av_assert0
[00:40:29 CEST] <thebombzen> I have a webcam that's outputting mjpeg with invalid DTS timestamps - they're basically random garbage. Is there a way to automatically generate the DTS timestamps so FFmpeg doesn't whine about nonmonotonically increasing DTS?
[01:36:28 CEST] <TAFB> how can I make ffmpeg play a playlist (can't use concat demuxer because the videos are different fps, etc.)???
[01:49:22 CEST] <pzich> Are you looking to play the output, or render it into one video with a conformed size and framerate?
[01:49:51 CEST] <pzich> If you're looking to play it, look in to ffplay, if you're looking to stream it as a server, look in to ffserver, etc.
[02:00:51 CEST] <TAFB> i'll check ffserver :) not much love for it on google.
[02:03:47 CEST] <utack> i have no idea what the alliance for open media is planning but i am currently testing what they released as encoder on an i7 with less than full hd and a preset they call "good" and speed is at a breath taking 7 frames per minute. no idea how far in develpment they are, but this is absurd
[10:21:55 CEST] <IamTrying> http://phoboslab.org/log/2013/09/html5-live-video-streaming-via-websockets - How can i FEED ffmpeg to Google chrome/Opera/Firefox in WebRTC as webcam source please?
[10:25:39 CEST] <IamTrying> Using FFMpeg, how to create a WebCam source? Which can be captured by Google chrome/Opera/Firefox as webCam source locally?
[10:46:41 CEST] <BtbN> IamTrying, you can't.
[10:47:04 CEST] <BtbN> ffmpeg is not a system driver.
[10:48:13 CEST] <IamTrying> BtbN: That will be horrible project in Windows then. how did ManyCam did in Windows.
[10:48:30 CEST] <BtbN> It comes with a system driver that simulates a webcam.
[10:48:32 CEST] <BtbN> FFmpeg is no driver.
[10:49:44 CEST] <IamTrying> OK
[13:04:14 CEST] <brontosaurusrex> My terminal is sliglty bork when ffmpeg exists, what was the solution to this?
[13:04:51 CEST] <zZap-X> why is flash player so slow at loading rtmp streams? i think its because my webcam is 15 fps and flash needs 60 frames before it starts showing
[13:32:32 CEST] <zZap-X> excellent, with a combination of -r 60 -framerate 60 the rtmp stream now starts in 3 seconds instead of 12 :D
[16:08:32 CEST] <benbro> can I create a virtual webcam with ffmpeg on windows?
[17:30:05 CEST] <explodes> av_input_probe_format seems to have returned a format whose codec has an AVFormat that is incorrect. there was is a failed assertion in sws_scale -> sws_setColorspaceDetails -> isYUV(srcFormat) -> av_assert0(av_pix_fmt_desc_get(fmt))
[17:30:22 CEST] <explodes> any reason av_input_probe_format returns bad results?
[17:32:37 CEST] <explodes> Also, here is a dumb little plea asking for consulting help from an expert of the ffmpeg c-library. http://pastebin.com/raw/iG7e0g2a
[18:58:24 CEST] <explodes> avio_alloc_context(>array of length 128KB<, >4 kilobytes<, 0, stream, ReadFunc, NULL, SeekFunc);
[19:30:51 CEST] <kadiro> hello, i have mkv video with embedded ttf font and ass, my question on how to replace the ttf font with one from the font directory?
[19:53:19 CEST] <furkan> i'm having trouble outputing to a file name with colons in it... does anybody know how i can handle that?
[19:54:01 CEST] <furkan> i tried putting it in quotes, and also preceding it by "file:"
[19:54:27 CEST] <explodes> what's the error?
[19:54:38 CEST] <furkan> file:/mnt/recordings/2016-04-14-Thursday-13:52:01.mp3: No such file or directory
[19:55:06 CEST] <explodes> oh. does "file:///mnt/path/to/thing.mp3" change the error?
[19:55:20 CEST] <furkan> hmm i'll try that thanks
[19:55:40 CEST] <kadiro> not bad as an easy question
[19:58:42 CEST] <furkan> explodes: still getting file:///mnt/recordings/2016-04-14-Thursday-13:58:01.mp3: No such file or directory
[19:58:56 CEST] <furkan> strange that it would say that for an output
[19:59:11 CEST] <furkan> like... the file isn't _supposed_ to be there lol
[19:59:30 CEST] <explodes> yea. try it without "file://"
[19:59:36 CEST] <explodes> not sure why you're putting it there anyway
[19:59:49 CEST] <furkan> oh it didn't work without it, so i was just trying different things
[19:59:49 CEST] <kadiro> How I CAn solve "Attachment stream 3 has no mimetype tag and it cannot be deduced from the codec id."
[20:00:03 CEST] <explodes> what was the error w/o it?
[20:00:22 CEST] <kadiro> av_interleaved_write_frame(): Invalid argument
[20:00:54 CEST] <kadiro> ffmpeg input.mkv -attach /usr/share/fonts/TTF/Khula-Regular.ttf -metadata:s:2 mimetype=application/x-truetype-font -c:v copy -c:a copy output.mkv
[20:01:36 CEST] <kadiro> furkan, '/mnt/recordings/2016-04-14-Thursday-13:58:01.mp3'
[20:03:23 CEST] Action: kadiro think is not in the right place to asking things about ffmpeg
[20:03:52 CEST] <benbro> is it possible to use ffmpeg to create a virtual webcam on windows?
[20:04:15 CEST] <kadiro> yes
[20:04:19 CEST] <furkan> lol kadiro: /mnt/recordings/$(date +"%Y-%m-%d-%A-%T").mp3: No such file or directory
[20:04:22 CEST] <furkan> damn crontab...
[20:04:44 CEST] <furkan> well i guess that's not crontab's fault
[20:04:52 CEST] <kadiro> furkan, what was the command?
[20:05:14 CEST] <furkan> 3 14 * * * ffmpeg -t 60 -i rtp://10.10.0.11:30001 -acodec copy '/mnt/recordings/$(date +"\%Y-\%m-\%d-\%A-\%T").mp3'
[20:05:56 CEST] <kepstin> it's in single-quotes - when that's passed to the shell, the single-quotes stop the shell from interpolating the date command
[20:06:16 CEST] <kadiro> benbro, something close to this: http://stackoverflow.com/questions/6766333/capture-windows-screen-with-ffmp…
[20:06:50 CEST] <kadiro> ah i guess is contab things
[20:07:00 CEST] <furkan> kepstin: yeah, figured, but with double-quotes, ffmpeg doesn't like the colons in the file name
[20:07:30 CEST] <furkan> i think it must be trying to interpret it as a protocol
[20:09:02 CEST] <furkan> yeah ok, same with inputs... ffmpeg doesn't want to open files that have a : in the file name
[20:09:34 CEST] <kadiro> i think that was the problem because single/double quotes are fine
[20:09:41 CEST] <benbro> kadiro: this is about screen capture. I'm trying to capture DirectShow input and output as a virtual webcam
[20:10:20 CEST] <kadiro> benbro, look in the link again, first answer
[20:11:02 CEST] <benbro> kadiro: first answer is: use a directshow screen capturer
[20:11:09 CEST] <kadiro> yes
[20:11:32 CEST] <benbro> I'm not interested in screen capture
[20:11:43 CEST] <benbro> I'm interested in creating a virtual webcam
[20:12:01 CEST] <kadiro> i bet that is related to ffmpeg imho
[20:12:22 CEST] <benbro> ?
[20:12:35 CEST] <benbro> related or unrelated?
[20:13:46 CEST] <kadiro> imho, ffmpeg can't do that
[20:14:27 CEST] <explodes> benbro: that's more of a video server kind of thing, I don't think that's in the realm of features of ffmpeg, too
[20:15:06 CEST] <explodes> if you're trying to make an endpoint that serves out video, ffmpeg isn't what you want. you'll want some kind of RTSP server
[20:15:09 CEST] <kadiro> benbro, may be this: http://fnd.tiddlyspace.com/fake%20webcam
[20:15:51 CEST] <explodes> whoa
[20:15:54 CEST] <explodes> cool.
[20:15:57 CEST] <kadiro> :)
[20:16:11 CEST] <kadiro> google is good :D
[20:17:19 CEST] <benbro> this is under linux. I'm using windows
[20:20:07 CEST] <kadiro> benbro, http://www.commentcamarche.net/download/telecharger-34081095-fake-webcam
[20:20:19 CEST] <kadiro> click on "Télécharger"
[20:26:29 CEST] <benbro> kadiro: I can search google too :)
[20:26:46 CEST] <benbro> I asked if ffmpeg can do it. it's probably out of scope
[20:28:41 CEST] <kadiro> benbro, yeah i know :) the first link show you how with ffmpeg ( in linux ), you are in windows the second link can do that, but if you insist to do with ffmpeg ask the guy create that module if he can help you to make it as an ( dll or something ) to be able to use it under windows :)
[20:31:17 CEST] <kadiro> benbro, you can use virtualbox and load a small or big ( depend on how much RAM you have ) linux iso then use that module :)
[20:31:52 CEST] <kadiro> I guess i gave you all the keys x)
[20:33:36 CEST] <kadiro> ah wait i think there an emulator used to be able to use some command from linux inside windows
[20:33:48 CEST] <kadiro> cygwin or something like that
[20:33:50 CEST] <kadiro> ?
[20:34:50 CEST] <kadiro> if so install git command and use this link to 'git clone it' and use the module under windows ( git is here : https://github.com/umlaeute/v4l2loopback )
[20:38:33 CEST] <benbro> kadiro: I'm looking for the equivalent fake camera in linux. not the other hacks. thanks
[23:16:01 CEST] <kadiro> I added a subtitle file as embeded but the player said no subtitle selected, what is wrong?
[00:00:00 CEST] --- Fri Apr 15 2016
1
0
[02:51:20 CEST] <jamrial_> BBB: checkasm started failing on some fate clients
[03:09:01 CEST] <BBB> jamrial_: I believe michaelni just fixed that
[03:09:16 CEST] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4d59d075a96c7bc9fc7a118f96…
[03:09:50 CEST] <BBB> it may take a while for that to relay to all clients
[03:29:58 CEST] <jamrial_> oh, ok
[03:30:06 CEST] <jamrial_> sorry for the ping then
[06:42:22 CEST] <cone-720> ffmpeg 03James Almer 07master:3674a53d1710: avformat/uncodedframecrc: fix incompatible pointer type warning
[08:40:55 CEST] <cone-720> ffmpeg 03Tobias Rapp 07master:ee104580c5b8: avfilter/vf_drawtext: add optional default value to metadata function
[09:18:24 CEST] <durandal_1707> nevcairiel: what you used for decoding 09 wmal track?
[09:41:45 CEST] <nevcairiel> durandal_1707: like i said on trac, the Microsoft decoder
[09:51:49 CEST] <durandal_1707> nevcairiel: that is utility/application/lib?
[09:53:41 CEST] <nevcairiel> "WMAudio Decoder DMO"
[09:53:53 CEST] <nevcairiel> (wmadmod.dll)
[10:28:48 CEST] <cone-720> ffmpeg 03Rodger Combs 07master:b20d3bf4a45d: lavc/audiotoolboxdec: avoid relying on consumer-provided params when possible
[10:28:49 CEST] <cone-720> ffmpeg 03Rodger Combs 07master:acd5910e39be: lavc/audiotoolboxdec: reindent
[10:28:50 CEST] <cone-720> ffmpeg 03Rodger Combs 07master:c11157c09a11: lavf/audiotoolboxdec: only send extradata for formats that use it
[10:28:51 CEST] <cone-720> ffmpeg 03Rodger Combs 07master:c890bcbacf32: lavf/audiotoolboxdec: only provide block alignment for ILBC
[11:29:36 CEST] <rcombs> Daemon404: sent new patches rebased against latest master (i.e. with codecpar); no warnings; no longer breaks DASH by default; works fine here
[11:56:12 CEST] <wm4> so how do I build ffmpeg in a way you can debug it? I tried with --enable-debug --disable-optimizations
[11:58:01 CEST] <wm4> ah need to add --disable-stripping
[11:58:04 CEST] <wm4> why is this so absurd
[11:58:39 CEST] <funman> isn't ffmpeg_g always generated regardless of --disable-stripping?
[11:58:44 CEST] <nevcairiel> you could just debug the ffmpeg_g variant which is not strpped
[11:59:21 CEST] <wm4> what if I'm not using ffmpeg CLI
[11:59:44 CEST] <wm4> will ffmpeg_g have the lib debug symbols even if they're built as dynamic libs?
[12:00:09 CEST] <wm4> maybe there should be something like --developer-mode that enables all the obscure stuff you need to actually debug libavcodec etc.
[12:00:41 CEST] <nevcairiel> shared libraries are only stripped in the install step, if you reference them from the source folder then they are intact
[12:01:29 CEST] <wm4> you can't build external code like this, unless you do convoluted things
[12:01:44 CEST] <nevcairiel> well then just build with disable stripping =p
[12:02:12 CEST] <funman> you can use LD_LIBRARY_PATH when running gdb so the unstripped libs are loaded
[12:02:16 CEST] <wm4> I'm using this with success: --enable-debug --disable-optimizations --disable-stripping
[12:02:35 CEST] <wm4> but now imagine someone wants to debug a program using libavcodec, and the problem appears to be in libavcodec
[12:02:57 CEST] <nevcairiel> enable debug isnt needed btw, its enabled by default
[12:03:25 CEST] <wm4> so what's the point of having that enabled by default, and stirpping it off by default
[12:03:41 CEST] <nevcairiel> because it produces ffmpeg_g as well
[12:04:04 CEST] <nevcairiel> if you work on any of the libs its often enough
[12:12:20 CEST] <pa> sorry for the OT question: do you guys know whether there exists an AV container that can be seeked before the file is closed? that is while it is being written
[12:15:29 CEST] <wm4> a what?
[12:15:30 CEST] <pa> for example if i want to transcode the stream from a DVB card, but i want to seek inside while ffmpeg is still capturing/transcoding
[12:15:49 CEST] <nevcairiel> use a streaming container like mpegts then
[12:15:53 CEST] <wm4> so you want to play a file that is being written by ffmpeg with a different program?
[12:15:59 CEST] <pa> yes
[12:16:09 CEST] <pa> like mplayer and then pgup /pgdown
[12:16:13 CEST] <pa> or <- / ->
[12:16:18 CEST] <ubitux> flv, mkv, webm should do
[12:16:31 CEST] <pa> ubitux, mkv? doesn't that write the index at the end?
[12:16:32 CEST] <nevcairiel> ubitux: mkv without a seeking index doesnt work well
[12:16:45 CEST] <wm4> mkv without seeking index works perfectly well, but can be slow
[12:16:58 CEST] <nevcairiel> being very slow isnt working "well" =p
[12:17:10 CEST] <ubitux> even avi should work, right?
[12:17:12 CEST] <wm4> depends how fast your IO is
[12:17:14 CEST] <nevcairiel> most demuxers will try to build their own index, or just blindly seek around in it
[12:17:32 CEST] <pa> well i'm asking for a container that somehow builds and store an incremental index
[12:17:43 CEST] <nevcairiel> for the second case, you might as well use mpegts then, which seems appropriate when recording a mpegts DVB stream anyway
[12:17:53 CEST] <pa> right..
[12:18:05 CEST] <pa> so with mpegts i can mplayer -ss quickly, right?
[12:18:22 CEST] <DHE> mpegts has no index. you just seek based on bitrate estimates, resync and look at the timestamps
[12:18:28 CEST] <nevcairiel> but i'm not aware of any container that writes an incremental index, the problem with that is that it would have to reserve space in the file somewhere, but it has no clue how much since it doesnt know how long the file is going to be
[12:18:31 CEST] <pa> ah okay
[12:18:46 CEST] <nevcairiel> hence seeking indexes are often at the end
[12:18:47 CEST] <pa> well it could build indexes in chunks
[12:18:55 CEST] <pa> and link to the next chunk at file offset
[12:18:57 CEST] <DHE> a fragmented index?
[12:19:01 CEST] <pa> yes
[12:19:16 CEST] <pa> each chunk could hold one hour or so
[12:19:19 CEST] <pa> configuragble perhaps
[12:19:27 CEST] <nevcairiel> honestly its not much of a practical use-case to design a container around =p
[12:19:38 CEST] <nevcairiel> seeking in mpegts is usually acceptably fast
[12:19:44 CEST] <pa> well if mpegts does it well, it's not needed indeed
[12:20:28 CEST] <nevcairiel> having an index would be faster of course, but its not like you really wait for an mpegts seek unless your IO is high latency
[12:20:49 CEST] <pa> right
[12:20:54 CEST] <pa> can try it out, thanks :)
[12:20:56 CEST] <av500> I think devices like PVRs build their own index files on the side
[12:21:06 CEST] <nevcairiel> thats always possible
[12:21:07 CEST] <av500> they record TS but also keep an index
[12:21:09 CEST] <pa> ah that would be an alternative
[12:21:14 CEST] <av500> fur stuff like timeshifting
[12:21:14 CEST] <pa> and embed it at the end
[12:21:28 CEST] <av500> TS cannot embed an index
[12:21:30 CEST] <pa> but does ffmpeg have such option?
[12:21:32 CEST] <av500> no
[12:21:52 CEST] <nevcairiel> somehow i thought there actually was some odd approach to load an index from somewhere else
[12:21:57 CEST] <nevcairiel> but maybe i'm thinking of something else
[12:22:15 CEST] <pa> that could be nice.. like when creating an mkv for example
[12:22:18 CEST] <pa> index file on the side
[12:22:21 CEST] <pa> embed it at the end
[12:22:30 CEST] <pa> or use it as separate index before the end
[12:23:23 CEST] <av500> but that would mean that the user app would need to know the filepos from the current frame in the MKV file
[12:23:28 CEST] <av500> from the muxer
[12:23:30 CEST] <pa> yes
[12:23:36 CEST] <av500> to write to the index
[12:23:39 CEST] <pa> it could for example be written in the container
[12:23:43 CEST] <pa> before closing it
[12:24:01 CEST] <pa> so at the end in place of the URL of the index, the actual index could be written
[12:24:22 CEST] <av500> well, the MKV muxer keeps an index in memory
[12:24:29 CEST] <av500> that it will write when you call close()
[12:24:35 CEST] <av500> so there is already an index
[12:24:42 CEST] <pa> right
[12:24:48 CEST] <pa> but can't be used by a player
[12:25:03 CEST] <pa> maybe i could try to hack ffmpeg
[12:25:06 CEST] <pa> to do that :)
[12:25:10 CEST] <av500> sure :)
[12:25:21 CEST] <av500> add an api to query the muxer index
[12:25:44 CEST] <pa> iirc mkv has options to add some empty space between the header and the first block
[12:26:02 CEST] <pa> where i could write the index url
[12:26:09 CEST] <av500> url?
[12:26:13 CEST] <pa> like file path
[12:26:33 CEST] <av500> "index in the cloud"
[12:26:36 CEST] <nevcairiel> referencing external files from media files is always a huge PITA
[12:26:38 CEST] <av500> make it a service :)
[12:26:55 CEST] <pa> nevcairiel, wouldn't abs path work?
[14:54:08 CEST] <Daemon404> rcombs, i will look
[14:54:15 CEST] <rcombs> thanks
[15:14:27 CEST] <Daemon404> rcombs, you should add maybe a verbose log or some documentation for the autobsf disabling behavior
[15:32:38 CEST] <cone-774> ffmpeg 03Diego Biurrun 07master:1a094af63828: fft: Split MDCT bits off from FFT
[15:32:38 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:546bf316cad2: Merge commit '1a094af638281295bf087945923d258b5acd1ab1'
[15:36:50 CEST] <cone-774> ffmpeg 03Luca Barbato 07master:d4066a702407: indeo2data: K&R formatting cosmetics
[15:36:51 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:6b1a0f205868: Merge commit 'd4066a702407352a0648af882c34ea81a404fa2b'
[15:38:50 CEST] <cone-774> ffmpeg 03Luca Barbato 07master:f8c34f4b8d62: indeo2: Fix banding artefacts
[15:38:51 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:78af369189eb: Merge commit 'f8c34f4b8d62afad3f63cf3d9617d73735bef8c1'
[15:39:40 CEST] <Daemon404> nevcairiel / michaelni - ping
[15:39:46 CEST] <Daemon404> next commit needs a new fate sample upload
[15:41:37 CEST] <Daemon404> who else can upload?
[15:42:06 CEST] <nevcairiel> you know how it goes, sample and place
[15:42:35 CEST] <Daemon404> http://fate-suite.libav.org/rt21/ISKATE.AVI
[15:42:42 CEST] <Daemon404> same place in our fate server
[15:45:11 CEST] <nevcairiel> Daemon404: done, please check
[15:45:33 CEST] <Daemon404> nevcairiel, rsync worked thanks
[15:50:57 CEST] <cone-774> ffmpeg 03Vittorio Giovara 07master:b39ab8549a53: fate: Add test for indeo2 with delta frames
[15:50:58 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:622f18a2bf46: Merge commit 'b39ab8549a53e2fc7978ab9db50e5c2ba6a6602d'
[16:06:44 CEST] <durandal_1707> nevcairiel: wmadmod.dll you used is for 64 bit?
[16:07:04 CEST] <nevcairiel> 32-bit i think, but i probably have both
[16:09:19 CEST] <durandal_1707> nevcairiel: md5 hash of it?
[16:10:16 CEST] <durandal_1707> mine is 03dea3b0b07a91fa145578a9973c24af
[16:10:18 CEST] <nevcairiel> durandal_1707: 0b7c5790893f3650162bed4bea35d9a6 *WMADMOD.DLL
[16:10:39 CEST] <nevcairiel> version 10.0.10586.63
[16:10:43 CEST] <nevcairiel> ie. latest windows 10 version
[16:21:18 CEST] <cone-774> ffmpeg 03Diego Biurrun 07master:11843ededacd: fate: Add separate target for all indeo3 tests
[16:21:19 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:884dd175f061: Merge commit '11843ededacd0157aea642771837557549b5b417'
[16:22:01 CEST] <Daemon404> nevcairiel, https://git.libav.org/?p=libav.git;a=commitdiff;h=1ceb07eb313c2d51383408025…
[16:22:08 CEST] <Daemon404> merge y/n?
[16:22:47 CEST] <nevcairiel> seems sensible, does it impact any fate results?
[16:22:54 CEST] <Daemon404> im going to run it
[16:36:24 CEST] <Daemon404> nevcairiel, no fate failures
[16:38:29 CEST] <cone-774> ffmpeg 03Anton Khirnov 07master:1ceb07eb313c: avformat_find_stream_info: move duration guessing after updating codec parameters
[16:38:30 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:3c461eecd48b: Merge commit '1ceb07eb313c2d51383408025e57a2fe50ccd164'
[16:47:53 CEST] <Daemon404> wow our asfenc code is REALLY different
[16:51:00 CEST] <RiCON> isn't it the old one?
[16:51:27 CEST] <RiCON> the libav asf is asf_o
[16:51:38 CEST] <Daemon404> asfenc
[16:51:48 CEST] <RiCON> disregard
[16:52:24 CEST] <Daemon404> 1ceff0859df1c4f6bfacd6c1cd9dbdcceb039423 asfenc: rename some variables
[16:52:31 CEST] <Daemon404> except it also changes where some stuff is stored
[16:52:35 CEST] <Daemon404> without explanation
[16:52:42 CEST] <Daemon404> so much for hunting for reasons why stuff is the way it is
[17:09:27 CEST] <cone-774> ffmpeg 03Anton Khirnov 07master:ff3db937ef3a: asfenc: fix some possible integer overflows
[17:09:28 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:bfd0f42277d1: Merge commit 'ff3db937ef3aa30046a3936146f86ad48ee2ff90'
[17:10:28 CEST] <cone-774> ffmpeg 03Anton Khirnov 07master:84b5dcf27589: asfenc: remove an unused variable
[17:10:29 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:3bf368a2a643: Merge commit '84b5dcf27589b32713a4ba0723a129156b4d2408'
[17:11:56 CEST] <cone-774> ffmpeg 03wm4 07master:7a6cf2771414: lavu: improve documentation of some AVFrame functions
[17:11:57 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:be6b58a98171: Merge commit '7a6cf2771414c7ab8bca0811d589f6091a6e2b71'
[17:15:05 CEST] <cone-774> ffmpeg 03wm4 07master:2e2f8534ebde: lavc: factor apply_param_change() AV_EF_EXPLODE handling
[17:15:06 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:f5b93c46e93a: Merge commit '2e2f8534ebde47d3a3909fe64c2e66204bc56874'
[17:15:22 CEST] <Daemon404> wm4, ping
[17:15:32 CEST] <Daemon404> whats up with "avconv: remove sub-frame warning"
[17:15:36 CEST] <Daemon404> it's in libav but not ours?
[17:15:41 CEST] <Daemon404> mailing list bikeshedding?
[17:15:59 CEST] <wm4> it's in ffmpeg.c too
[17:16:06 CEST] <wm4> you can probably skip it for now
[17:16:13 CEST] <wm4> michaelni was against removing it this way
[17:17:04 CEST] <Daemon404> ok
[17:17:59 CEST] <cone-774> ffmpeg 03wm4 07master:0b6e5d6b32b9: avconv: remove sub-frame warning
[17:18:00 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:e7ac968f60dd: Merge commit '0b6e5d6b32b91c6da79cd919a3c2ede9d682f838'
[17:22:33 CEST] <cone-774> ffmpeg 03Vittorio Giovara 07master:d40cb726d271: mov: Trim dref absolute path
[17:22:34 CEST] <cone-774> ffmpeg 03Vittorio Giovara 07master:e10b7ef2fe56: vdpau: Add missing deprecation guards
[17:22:35 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:feb1f7abc587: Merge commit 'd40cb726d271b0284642a1ba159eb26a5c579f77'
[17:22:36 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:09dc6845662b: Merge commit 'e10b7ef2fe56603fb1baac6b20fd6bd0a3fdd0d0'
[17:26:11 CEST] <cone-774> ffmpeg 03Katerina Barone-Adesi 07master:1389b4c18d10: idct8x8: Fix undefined negative shifts
[17:26:12 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:eff2b4311750: Merge commit '1389b4c18d1042c196603ba66c25113bcee1738b'
[17:29:52 CEST] <cone-774> ffmpeg 03Luca Barbato 07master:7d4a1ff344cb: mpegvideo: Fix undefined negative shifts in ff_init_block_index
[17:29:54 CEST] <cone-774> ffmpeg 03Luca Barbato 07master:024235139064: mpegvideo: Fix undefined negative shifts in mpeg_motion_internal
[17:29:54 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:c2f9f8165009: Merge commit '7d4a1ff344cbf969ac648642a0fd8484fd5b8637'
[17:29:55 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:d3e1c6f97502: Merge commit '0242351390643d176b10600c2eb854414f9559e6'
[17:31:56 CEST] <cone-774> ffmpeg 03Luca Barbato 07master:39a2d3288e82: mpegvideo: Refactor emulated_edge_mc calls
[17:31:56 CEST] <michaelni> Daemon404, 3c461eecd48ba2cf7616d98e6f99954de3ad4b06 breaks chapter durations
[17:31:57 CEST] <cone-774> ffmpeg 03Derek Buitenhuis 07master:f8b09e90e92c: Merge commit '39a2d3288e82e4e576c03efb32179ef5a19fff50'
[17:32:18 CEST] <Daemon404> michaelni, breaks how
[17:32:22 CEST] <Daemon404> also we should add a fate test
[17:32:37 CEST] <michaelni> ./ffprobe -i ~/tickets/1833/vorbis_chapter_extension_demo.ogg
[17:32:43 CEST] <michaelni> Chapter #0:3: start 15.000000, end 15.000000
[17:32:56 CEST] <michaelni> was: Chapter #0:3: start 15.000000, end 19.849000
[17:33:01 CEST] <nevcairiel> probably should move the compute_chapters_end to later in the function as well
[17:33:24 CEST] <nevcairiel> since it uses the duration
[17:33:28 CEST] <Daemon404> that would probablt fix it yes
[17:34:18 CEST] <Daemon404> michaelni, should be able to add a fate test with that file, using -show_chapters
[17:35:28 CEST] <michaelni> yes, please add one if you can, ill try to test more
[17:35:45 CEST] <Daemon404> building right now
[17:38:40 CEST] <michaelni> '39a2d3288e82e4e576c03efb32179ef5a19fff50' also changes stream-program assignment in tickets//2441/Pirunpelto_cut.ts
[17:38:57 CEST] <michaelni> Stream #0:0[0x44](fin): Audio: mp2 is no longer in program 1 but "No Program" after it
[17:39:14 CEST] <nevcairiel> that seems odd, why would a avcodec change do that
[17:40:23 CEST] <Daemon404> michaelni, yum did you quote teh wrong hash
[17:40:32 CEST] <Daemon404> 39a2d3288e82e4e576c03efb32179ef5a19fff50 merge is a no-op
[17:41:46 CEST] <michaelni> 3c461eecd48ba2cf7616d98e6f99954de3ad4b06 dunno how i got that other hash
[17:42:21 CEST] <Daemon404> michaelni, we can just revert if you wish
[17:43:18 CEST] <nevcairiel> moving that causes program assignment to change? still seems odd
[17:45:38 CEST] <Daemon404> nevcairiel, ofc
[17:47:14 CEST] <michaelni> i also see changes in subtitles from it
[17:48:26 CEST] <Daemon404> how come none of this was caught by fate
[17:48:50 CEST] <michaelni> ./ffmpeg -i ~/tickets/1332/Starship_Troopers.vob -vn -an -scodec copy -f framecrc -
[17:48:53 CEST] <Daemon404> seems pretty weird to have all these changes from moving that down
[17:49:02 CEST] <michaelni> i dont get it either
[17:49:09 CEST] <nevcairiel> seems unlikely infact
[17:50:58 CEST] <Daemon404> we have a ton of code in between that libav doesnt
[17:51:03 CEST] <Daemon404> i may have moved it too far down
[17:51:29 CEST] <michaelni> it probably interacts with av_opt_set(ic, "skip_clear", "0", AV_OPT_SEARCH_CHILDREN);
[17:52:15 CEST] <michaelni> i slightly tend toward a revert atm but ive not looked at later commits much yet
[17:52:34 CEST] <Daemon404> most of the later commits are no-ops.
[17:55:54 CEST] <michaelni> ahh, if i commet out the timings entirely subtitles in Starship_Troopers.vob disappear entirely
[17:56:37 CEST] <michaelni> so they get detected during estimate_timings() probably and the loop it was moved over needs the subtitles to be detected
[17:57:07 CEST] <Daemon404> thats seems odd to be... detecting in estimate_timings...
[18:00:00 CEST] <michaelni> also by moving estimate_timings outside skip_clear it will remove streams from programs
[18:00:36 CEST] <michaelni> that is when during timing search it encounters a program table thingy without the stream
[18:01:22 CEST] <michaelni> ATM i think this commit should be reverted, did what it fixed even fail in ffmpeg ?
[18:02:17 CEST] <Daemon404> avformat_find_stream_info: move duration guessing after updating codec parameters
[18:02:20 CEST] <Daemon404> from the commit message
[18:02:22 CEST] <Daemon404> This bitrate might not be known otherwise.
[18:02:25 CEST] <Daemon404> Bug-Id: 926
[18:02:54 CEST] <Daemon404> https://bugzilla.libav.org/show_bug.cgi?id=926
[18:04:17 CEST] <michaelni> where can i find the file mentioned in the bug ? or am i silly and teres a lnk?
[18:04:39 CEST] <Daemon404> "on any mp3"
[18:06:53 CEST] <michaelni> ahh, the bug also says "Note duration is N/A. Now compare the same with ffprobe:" <-- i guess that means it worked fine in ffmpeg
[18:07:08 CEST] <Daemon404> this is pre-codecpar ffmpeg though
[18:07:15 CEST] <Daemon404> i would check just in case
[18:08:36 CEST] <Daemon404> trying..
[18:08:43 CEST] <michaelni> pre codecpar Duration: 00:04:53.30, start: 0.000000, bitrate: 256 kb/s, post codecpar: Duration: 00:04:53.30, start: 0.000000, bitrate: 256 kb/s
[18:08:49 CEST] <michaelni> with random mp3
[18:08:55 CEST] <Daemon404> . Duration: 00:00:01.04, start: 0.025057, bitrate: 131 kb/s
[18:09:01 CEST] <Daemon404> i reverted the merge
[18:09:04 CEST] <Daemon404> and i still get a duration
[18:09:08 CEST] <Daemon404> (mp3 is from fate)
[18:09:25 CEST] <Daemon404> so it is probably safe to revert
[18:09:31 CEST] <michaelni> yes
[18:09:50 CEST] <Daemon404> ill push it
[18:11:30 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:2691a8399f57: Revert "Merge commit '1ceb07eb313c2d51383408025e57a2fe50ccd164'"
[18:17:01 CEST] <michaelni> thx
[18:26:31 CEST] <cone-248> ffmpeg 03Anton Khirnov 07master:7480d001312d: pixfmt: fix the AV_PIX_FMT_VAAPI_VLD doxy
[18:26:32 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:27558679a1e0: Merge commit '7480d001312d9ba706333ec970264ed9df3f82cb'
[18:27:13 CEST] <cone-248> ffmpeg 03Anton Khirnov 07master:328e9a15c568: buffer: drop a reference to a non-existing function from the docs
[18:27:14 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:c849ed8b2fa2: Merge commit '328e9a15c568843580ff3ff490748d545f16def8'
[18:29:28 CEST] <cone-248> ffmpeg 03Luca Barbato 07master:c11a85862645: configure: Support msan as toolchain
[18:29:29 CEST] <cone-248> ffmpeg 03Luca Barbato 07master:59b9d2f684f1: configure: Add support for clang llvm-cov
[18:29:30 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:6e6b1fe7f714: Merge commit 'c11a8586264520e6afcddc52156f4a1fd2fb07b2'
[18:29:31 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:37f4cdb93780: Merge commit '59b9d2f684f1ff66627ca2b7d2dd05771ade62f0'
[18:31:05 CEST] <cone-248> ffmpeg 03Luca Barbato 07master:7e01d48cfd16: mov: Check the entries value when parsing dref boxes
[18:31:06 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:bdd6275691dc: Merge commit '7e01d48cfd168c3dfc663f03a3b6a98e0ecba328'
[18:31:48 CEST] <cone-248> ffmpeg 03Luca Barbato 07master:92c1a83ee939: qsv: Fix loading multiple plugins
[18:31:49 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:c1828450686c: Merge commit '92c1a83ee9394b39d68f6affd9104752a03714f8'
[18:34:35 CEST] <cone-248> ffmpeg 03Luca Barbato 07master:8b4b1c1eea9d: matroska: Support V_QUICKTIME as written in the specification
[18:34:36 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:e5bb7d98f8c0: Merge commit '8b4b1c1eea9daa4e2003aa0935e73f56aab8102d'
[18:35:55 CEST] <cone-248> ffmpeg 03Sean McGovern 07master:2f4a1bb9bfb2: cmdutils: update copyright year to 2016
[18:35:56 CEST] <cone-248> ffmpeg 03Derek Buitenhuis 07master:89ec4d46eedf: Merge commit '2f4a1bb9bfb29112711ba904e1dc0dd58e24f361'
[19:32:20 CEST] <jamrial> michaelni: could you look at the updated ref files for force_key_frames and gapless-mp3 tests in the framecrc patch?
[19:32:44 CEST] <jamrial> either the one you sent some weeks ago or mine from last night
[19:33:09 CEST] <jamrial> is that new output intended?
[19:35:18 CEST] <michaelni> jamrial, i think these md5s are taken from framecrc or something data, the change is probably ok but they probably shouldt be md5s that way to begin with
[19:36:02 CEST] <michaelni> that is md5s of "text" from framecrc
[19:36:22 CEST] <michaelni> the size and "PSNR" also suggest that
[19:36:30 CEST] <jamrial> alright
[19:37:19 CEST] <jamrial> just re-ran fate to update the couple tests Daemon404 merged earlier today as well. going to push now
[19:40:28 CEST] <cone-248> ffmpeg 03James Almer 07master:33aa8a62219d: avformat/framecrc: enable new output
[19:43:40 CEST] <cone-248> ffmpeg 03James Almer 07master:5557e881c9e5: avformat/framehash: add extradata checksum
[20:45:06 CEST] <cone-248> ffmpeg 03Lou Logan 07master:fa0f59d55d93: doc/demuxers: fix "Quicktme" typo
[21:41:49 CEST] <durandal_1707> ok to push wmal patch, nobody cares for speedup drop?
[21:44:21 CEST] <nevcairiel> if you add it to floatdsp then someone could make it fast later
[21:44:25 CEST] <nevcairiel> eh losslessdsp
[21:44:26 CEST] <nevcairiel> sorry
[21:44:43 CEST] <nevcairiel> otherwise accurate decoding is more important than speed
[21:58:17 CEST] <durandal_1707> its not perfect, but much better than before
[22:40:57 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:3c0511f29e9e: tests/checkasm/vf_colorspace: Make bpp_mask const
[23:02:33 CEST] <cone-248> ffmpeg 03Paul B Mahol 07master:5ac71e9db84c: avcodec/wmalosslessdec: improve >2 channel support
[23:02:34 CEST] <cone-248> ffmpeg 03Paul B Mahol 07master:56759f69a601: avcodec/wmalosslessdec: improve 24bit support
[00:00:00 CEST] --- Thu Apr 14 2016
1
0
[00:30:56 CEST] <pfelt> afternon all. i'm playing around with send_command and had a question. is there any way to send a command from an external program?
[00:31:59 CEST] <pfelt> also, if i have two instances of a given filter, is there a way to specify which of the instances should process the command?
[00:39:15 CEST] <explodes> Why does a 1080x720 image with BGR24 pixel format give me 3 * 1280 * 720? (av_image_get_buffer_size)
[00:45:50 CEST] <kepstin> it might have just rounded it up for alignment, and I think parts of ffmpeg require a little extra space after the buffer for various reasons
[00:46:33 CEST] <kepstin> if you used the crop filter on a larger image, it just adjusts some pointers and width/height/stride numbers, it doesn't actually change the buffer size
[01:01:53 CEST] <petecouture> Problem: Your input is RTP live and output is HLS live. Occasionally the RTP feed drops but doesn't disconnect. When the feed comes back ffmpeg doesn't encode any new frames.
[01:02:19 CEST] <petecouture> Question: Is there a flag or procol to set to overcome that or do you have to shut down ffmpeg and start the encoder.
[01:02:30 CEST] <Prelude2004c> hey guys.. good day
[01:02:37 CEST] <petecouture> good day Relude
[01:02:41 CEST] <petecouture> Prelude rather
[01:02:43 CEST] <Prelude2004c> i am sooo really stuck... can i get some help .. Non-monotonous DTS in output stream . over time this happens and id ont know what to do about it
[01:03:11 CEST] <Prelude2004c> its random, comes and goes.. and i would like to say i tried everything likely not since its still broken
[01:03:11 CEST] <Prelude2004c> :)
[01:05:05 CEST] <petecouture> Whats the input output?
[01:05:41 CEST] <Prelude2004c> http://pastebin.com/Q97V3a3J
[01:05:57 CEST] <Prelude2004c> see that code.. the output works well for a while and then randomly.. bahm.. !! it dies off.
[01:06:03 CEST] <Prelude2004c> have to restart stream again
[01:06:35 CEST] <Prelude2004c> tried to add " itsoffset 0 -vsync passthrough -fflags +genpts -ss 0 " .. i also tried vsync 1 async 1.. everything.
[01:06:44 CEST] <Prelude2004c> nothing fixes it :( ..
[01:09:32 CEST] <petecouture> Hmmm first glance this is taking from a hardware transcoder and outputing to a live m3u8 stream?
[01:10:48 CEST] <Prelude2004c> yes its a UDP source.. i am transcoding with NVIDIA hardware and then segmenting it back with m3u8
[02:24:37 CEST] <blue_misfit> Prelude2004c, tried any other formats? Maybe your encoder can make RTMP or something?
[02:36:45 CEST] <TAFB> how can I loop a playlist with ffmpeg? Using 3.0.1 :)
[02:38:29 CEST] <TAFB> my command right now, only loops one file: ffmpeg -re -stream_loop -1 -i video.mp4 -c copy -vbsf h264_mp4toannexb -flags -global_header -hls_time 60 -hls_list_size 600 -hls_wrap 600 -start_number 1 /HLS/live/mystream/index.m3u8
[03:18:32 CEST] <krompus> hey guys
[03:19:11 CEST] <krompus> My friend asked me an interesting question. Is there any way of converting 360 degree video to 2D? basically raise the FOV?
[04:27:59 CEST] <TAFB> where do I put "safe 0" for concat??
[04:33:06 CEST] <c_14> TAFB: before -i on the concat input
[04:33:32 CEST] <TAFB> ok, thanks! I tried it but I'm getting "Packet header is not contained in global extradata, corrupted stream or invalid MP4/AVCC bitstream"
[04:33:39 CEST] <TAFB> Failed to open bitstream filter h264_mp4toannexb for stream 0 with codec copy: Invalid argument
[04:34:12 CEST] <TAFB> full command line: ffmpeg -re -stream_loop -1 -f concat -safe 0 -i list.txt -c copy -vbsf h264_mp4toannexb -flags -global_header -hls_time 60 -hls_list_size 600 -hls_wrap 600 -start_number 1 /dev/shm/mystream/index.m3u8
[04:36:07 CEST] <c_14> It looks like it doesn't like (one of) your input videos
[04:36:18 CEST] <c_14> Have you tried getting rid of the vbsf?
[04:36:29 CEST] <TAFB> i'll try :)
[04:37:03 CEST] <TAFB> works, I'll see if the HLS is corrupted though, that's why I had to put that filter in :) 1 sec.
[04:42:45 CEST] <TAFB> looks like it's working but when it gets to the end of the playlist, it doesn't loop.
[04:42:54 CEST] <TAFB> stream_loop 1 was making it loop before :)(
[04:55:51 CEST] <c_14> I don't think I've ever had stream_loop loop the concat demuxer, let me test
[04:58:41 CEST] <c_14> nope, wont loop
[05:02:08 CEST] <TAFB> bummer
[05:02:25 CEST] <TAFB> any way to make it loop without breaking the stream you think? :(
[05:04:14 CEST] <c_14> for i in `seq 9001`; do cat concat >> concat; done
[05:05:29 CEST] <TAFB> that might work, lol
[05:06:17 CEST] <c_14> I don't care how short your videos are, you won't reach the end of that list.
[05:07:07 CEST] <TAFB> i'm running it now :)
[05:07:26 CEST] <c_14> eeeh, I do hope you didn't copy that exactly
[05:07:31 CEST] <c_14> your hdd probably isn't big enough
[05:08:24 CEST] <TAFB> i just copied the file around 100 times over
[05:08:37 CEST] <c_14> Ok, that should be enough
[05:09:02 CEST] <c_14> 2^9000 copies would be a _tad_ bit overkill
[05:13:38 CEST] <TAFB> looks like it messes up when it gets to the third file in the list, speed 3.75x?!? :(
[05:14:04 CEST] <c_14> Are the files all the same format? codec, pixel format, etc?
[05:14:31 CEST] <TAFB> they should be but it's spitting out "[mov,mp4,m4a,3gp,3g2,mj2 @ 0x362c560] Auto-inserting h264_mp4toannexb bitstream filter" as it's playing
[05:14:37 CEST] <TAFB> I needed that filter before to fix the same problem
[05:15:07 CEST] <c_14> Does it do that once or every time it switches files?
[05:15:23 CEST] <TAFB> i think so
[05:15:35 CEST] <c_14> Which?
[05:16:08 CEST] <TAFB> which what?
[05:16:21 CEST] <c_14> 03:15 <c_14> Does it do that once or every time it switches files?
[05:16:31 CEST] <TAFB> every time it switches files
[05:16:39 CEST] <c_14> hmm
[05:16:59 CEST] <c_14> And it messes up at the third file?
[05:17:03 CEST] <TAFB> and after it messed up on the 3rd file, it stops writing to index.m3u8
[05:17:16 CEST] <c_14> Is the output video grey or black?
[05:17:28 CEST] <c_14> after it messes up?
[05:17:34 CEST] <TAFB> the live stream player says "error loading media, next segment not found"
[05:18:17 CEST] <TAFB> to rule it out being a video problem I've repeated video 1 twenty times in the playlist, same issue
[05:19:05 CEST] <c_14> What you could do is remuix each of the input videos to mpegts individually and then run concat on those
[05:21:07 CEST] <TAFB> I think the best option would be to run a ffpeg with the stream_loop 1 and send the stream to ffpeg to make the HLS stuff. Should be possible right?
[05:22:23 CEST] <c_14> if you can get it working, sure
[05:22:50 CEST] <TAFB> i think that'll be the best option :(
[05:28:52 CEST] <TAFB> hls_playlist_type event
[05:29:18 CEST] <TAFB> looks like I can just append the index.m3u8 instead of it overwriting it each loop.
[05:29:34 CEST] <TAFB> but the longer I run it the more segment video files it'll dump on the server, lol :(
[05:45:50 CEST] <TAFB> lol! My ISP throttles videos (youtube, etc.) and it was throttle my stream really bad
[05:46:08 CEST] <TAFB> I changed the filenames from .ts to .html and no more throttling, SUPER fast now! lol
[05:48:31 CEST] <TAFB> ahhh, fix it. :)
[05:48:57 CEST] <TAFB> i transcoded all the videos into one video file, and just used the stream_loop on that one large video, works flawless.
[05:52:02 CEST] <petecouture> Peoples opinions on ffserver?
[05:54:00 CEST] <furq> it's bad
[05:54:02 CEST] <furq> don't use it
[06:15:38 CEST] <Xen0> right now to go from a mkv with .ass subtitles i have been using the -vf ass=sub.ass whith h264 but my end goal is webm with libvpx so im basically encoding twice am i wasteing time doing this or will video filter flag work with libvpx?
[06:15:53 CEST] <furq> of course it will
[06:16:31 CEST] <Xen0> oh
[06:16:39 CEST] <furq> what gave you the impression it wouldn't
[06:16:58 CEST] <Xen0> nothing jus i couldnt find anything saying implicitly that it would
[06:20:49 CEST] <thebombzen> is there a way to get FFmpeg to render ASS subs with libass in one shot? currently I have to dump the font attachments, install them, extract the subs with -c copy, and then run -vf ass. is there an easier way to do it, like how mpv or mplayer can render the subs directly from the original container?
[06:22:37 CEST] <relaxed> thebombzen: to hardsub, ffmpeg -i video.mkv -vf subtitle=video.mkv ...
[06:23:53 CEST] <relaxed> er, -vf subtitles= https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo
[06:27:09 CEST] <Xen0> if you use subtitles=foo.mkv you dont have to map the stream?
[06:28:03 CEST] <Xen0> or no so long as its the default language?
[06:28:21 CEST] <thebombzen> no apparently that worked, huh
[06:28:46 CEST] <thebombzen> I had tried that before, but there were []s in my filename so I didn't realize I had to escape it
[06:28:59 CEST] <thebombzen> is there any easy way to escape a filename for use in an FFmpeg filter?
[06:29:57 CEST] <relaxed> Xen0: it picks the default, but you can change it with the filter
[06:31:23 CEST] <thebombzen> relaxed: is there a way to render ASS subs with -filter_complex?
[06:31:42 CEST] <thebombzen> specifying the filename twice just seems bad to me
[06:31:55 CEST] <Xen0> ok that makes sense thank for your guys help
[06:32:22 CEST] <Xen0> iv been makeing extra work for myself out of ignorance
[07:21:25 CEST] <relaxed> thebombzen: pretty sure you have to use the filename with subtitles filter
[07:21:38 CEST] <thebombzen> darn
[07:21:56 CEST] <thebombzen> escaping filenames in the ASS filter is annoying
[07:22:00 CEST] <thebombzen> or the subtitles filter
[07:23:28 CEST] <relaxed> for i in *.mkv; do ffmpeg -i "$i" -vf subtitles="$i" output; done
[07:27:42 CEST] <petecouture> can multiple ffmpeg connections attach to a single rtp broadcast? I'm trying to spawn two ffmpeg commands with the same sdp file connecting to a rtp broadcast
[07:27:59 CEST] <petecouture> Not sure if I'm doing that right. Some examples I see show ffmpeg with a single input and multiple outputs
[08:07:19 CEST] <petecouture> Sweet, ok I figured out to do multibit rate from the same command line.
[08:08:36 CEST] <petecouture> So question. I'm transcoding a single live stream to a multiple HLS outputs. For those with experience, if/how would I align an audio only track to a video track? Or do I not need to?
[08:14:06 CEST] <petecouture> Never mind. The segments are created at the same time so it's aligned
[09:53:28 CEST] <pikaro> hi! I can't find the documentation for the hotkeys in ffmpeg command line. when I press the left arrow key, it apparently increases a parameter called debug, right opens a command prompt, and there appear to be more. I have no idea how to stop some of the behaviors they produce, for instance one turns on some kind of debug mode that fills the terminal with massive amounts of spew. any help?
[10:20:36 CEST] <Guest85077> I am trying to encode a m3u8 url using ffmpeg and i get alot of
[10:20:37 CEST] <Guest85077> skipping 1 segments ahead, expired from playlists
[10:21:11 CEST] <Guest85077> So wondered if someone could help me encode/transcode a m3u8 url to rtmp
[10:24:38 CEST] <Guest85077> i have a strong feeling that its due to connectivity of origin m3u8 url (buffering/stuttering etc) but can anything be done to make the rtmp not halt. like inforce a delay in the stream
[13:30:11 CEST] <StyXman_> do video files have an equivalent of exif? if so, how can I access them with libav or similar?
[14:34:56 CEST] <DHE> are the doxygen docs for ffmpeg available for download? building them is... annoying.
[15:11:41 CEST] <sasha> I'm struggling with doing a double pass with ffmpeg, I keep getting [NULL @ 0x7fbd01804800] Unable to find a suitable output format for '1'
[15:12:14 CEST] <sasha> the command I'm using: ffmpeg -b:v $bitrate -pass 2 -v warning -i $input -i $palette -lavfi "$filters [x]; [x][1:v] paletteuse" -y $output
[15:12:44 CEST] <sasha> filters are filters="fps=10,scale=$scale:-1:flags=lanczos"
[15:12:50 CEST] <sasha> any ideas where I'm going wrong?
[15:13:04 CEST] <sasha> I'm trying to generate a gif that fits within out issue trackers' file size limit
[15:17:43 CEST] <sasha> nevermind, my input bitrate was a number and not appended with anything (k)
[15:49:19 CEST] <Prelude2004c> hey guys.. good day
[15:49:26 CEST] <Prelude2004c> having some serious issues wiht " Non-monotonous DTS in output stream " can anyone help?
[15:49:35 CEST] <Prelude2004c> not sure but randomly i keep getting errors with : Non-monotonous DTS in output stream
[15:50:06 CEST] <Prelude2004c> i am capturing the stream in UDP > Transcoding with NVidia Hardware > and merging audio/video back with ffmpeg.. somehow Non-monotonous DTS in output stream pops up on channels once in a while and the only solution is to restart the stream
[15:50:08 CEST] <Prelude2004c> any ideas ?
[15:53:37 CEST] <jkqxz> Prelude2004c: What is actually wrong? Is the output invalid somehow?
[15:53:53 CEST] <Prelude2004c> no its valid.. somehow DTS starts to drift over time
[15:54:07 CEST] <Prelude2004c> when i restart its ok. someimtes for a day ... sometimes for two.. the source is satelite so ..
[15:54:21 CEST] <Prelude2004c> its very unpredicatable but using another encoder i have no issues.. but they don't use ffmpeg
[15:54:44 CEST] <Prelude2004c> the errors may exist but the encoder handles it .. i tried to vsync and async but nothing.. in fact soon as i run async it overloads the cpu's
[15:54:53 CEST] <Prelude2004c> i guess due to the -af having to look at al the packets
[15:58:35 CEST] <Prelude2004c> i don't know what to do so the system continues or tries to keep the audio/video in sync
[15:58:40 CEST] <Prelude2004c> and not exit with errors
[15:58:43 CEST] <jkqxz> If the output is valid, what is the problem?
[16:02:02 CEST] <Prelude2004c> its not.. the ffmpeg starts to crash and doesn't write the output
[16:02:28 CEST] <Prelude2004c> i get the " Non-monotonous DTS in output stream " .. and then the segments stop writing
[16:02:38 CEST] <yzT> hi! a question not directly about ffmpeg, but guess you may know the answer. Is CENC applicable to HLS? Or just to MPEG-DASH?
[16:02:59 CEST] <yzT> is there any other channel about streaming in Freenod?
[16:04:13 CEST] <JEEB> yzT: CENC is MPEG-DASH specific
[16:04:27 CEST] <JEEB> HLS standard encryption also uses AES-128, but IIRC in another mode
[16:04:35 CEST] <yzT> ok, that's why I thought
[16:04:45 CEST] <JEEB> but the "Common Encryption" specification is an addition to MPEG-DASH
[16:04:52 CEST] <JEEB> since it talks about the manifest etc
[16:05:31 CEST] <yzT> so, for HLS there is no standard for different DRM, right?
[16:06:02 CEST] <JEEB> there is no standard DRM for HLS, only the standard AES-128 where you have a link towards the key in the playlist
[16:06:42 CEST] <andrey_utkin> is there some filter just to change opacity of frame? i need it to overlay bigger frame afterwards. So "blend" doesn't work. Maybe "geq" would do the work, but "geq=alpha_expr=0.5" gives error "A luminance or RGB expression is mandatory" which I'm not sure how to overcome.
[16:07:03 CEST] <yzT> ok cool
[16:07:36 CEST] <colde> yzT: well, there is to different AES encryptions that are standard for HLS
[16:08:03 CEST] <colde> But there is no DRM component in the format itself
[16:08:24 CEST] <colde> There is however DRM versions that work for HLS, and usually it is just a matter of adding an extra line tot he manifest
[16:08:37 CEST] <durandal_1707> andrey_utkin use blend with expression
[16:10:05 CEST] <yzT> colde: but in this case, I'd need to integrate each DRM system, right?
[16:10:29 CEST] <yzT> Is there any free solution of a keyserver for testing purposes?
[16:10:33 CEST] <colde> yzT: yeah, but you sort of need to do that with CENC as well
[16:11:04 CEST] <colde> yzT: you can use a HTTP server as a keyserver if you are worried about testing the encryption implementation
[16:11:09 CEST] <yzT> I thought CENC's purpose was precisely to be transparent ><
[16:11:27 CEST] <colde> yzT: it is transparent, and the way it is encrypted is the same
[16:11:37 CEST] <colde> yzT: but the specific headers for each DRM system is still present
[16:12:03 CEST] <yzT> ok
[16:13:11 CEST] <colde> yzT: just out of curiosity, what are you trying to build?
[16:13:39 CEST] <yzT> anything at all. Just trying to understand the security behind the HLS and DASH ecosystem
[16:14:29 CEST] <colde> yzT: CableLabs have a very good overview for DASH here: https://html5.cablelabs.com/mse-eme/doc/overview.html
[16:14:53 CEST] <colde> With two of the very common DRM vendors as well as the completely open ClearKey implementation
[16:15:04 CEST] <yzT> cool, ty
[16:16:25 CEST] <colde> yzT: oh, and MS is fairly open about their standards for the DRM ecosystem: https://www.microsoft.com/playready/documents/
[16:16:29 CEST] <colde> you are welcome :)
[16:20:46 CEST] <Prelude2004c> just had the new error again : ] Non-monotonous DTS in output stream 0:1; previous: 10212962684, current: 1656568443; changing to 10212962685. This may result in incorrect timestamps in the output file.
[16:20:50 CEST] <yzT> so, let me clarify the scenario.. xD two companies (the content maker) A and B have a different DRM system. Then another company (the streaming provider) C uses CENC to integrate the DRM of A and B. And finally the user sees the video by using either HLS or DASH
[16:21:07 CEST] <Prelude2004c> anyone know how i can prevent ffmpeg from exiting out or correcting this error
[16:22:03 CEST] <jkqxz> Prelude2004c: Does "-vsync 0" change the behaviour at all?
[16:25:39 CEST] <BtbN> that's not an error, it does not cause ffmpeg to exit.
[16:25:55 CEST] <BtbN> And it usually means your input data is broken.
[16:26:16 CEST] <Prelude2004c> no tried that
[16:26:30 CEST] <Prelude2004c> let me show you the code i am working with
[16:27:29 CEST] <Prelude2004c> http://pastebin.com/GTZU33ae
[16:28:42 CEST] <Prelude2004c> i am working with an over the air and satelite feed... i can't change the source .. but i have to somehow adjust for the error and stuff... So i am taking an over the air satelite source.. > UDP MULTICAST > ffmpeg input > transcode with nvidia hardware > output to ffmpeg and encode audio ... then segment out
[16:29:26 CEST] <learner123woo> Hello. I wrote my first little python app that records entire screen+audio using avconv and I'm pretty happy with that
[16:29:27 CEST] <Prelude2004c> -vsync 1 -fflags +genpts i added this to play with it but..
[16:30:14 CEST] <learner123woo> Now I would like to go one step forward and make the app capture only one browser tab and its audio. Can someone more experienced tell me if it is possible?
[16:33:55 CEST] <Prelude2004c> should i try to use -frame_drop_threshold ?
[16:35:41 CEST] <Prelude2004c> or even -start_at_zero ?
[16:35:42 CEST] <andrey_utkin> durandal_1707, but with blend i need to pad my overlay image and I don't see how do make it not to break the padded zone. This command kind of succeeds, but all other background picture is affected by blending. https://gist.githubusercontent.com/andrey-utkin/7d9e335765b23913ff7fd1e11b9…
[16:40:03 CEST] <Prelude2004c> BtbN ? your usually very good at this sort of stuff
[16:40:03 CEST] <colde> yzT: What you are describing is certainly possible. But it would mean sharing the keys tot he content. And would for anything but DASH most likely require several renditions
[16:40:14 CEST] <colde> yzT: or using something like unified streaming to formatshift on the fly
[16:45:28 CEST] <jkqxz> Prelude2004c: Does NvTranscoder (I'm assuming that's the nvenc example program) actually take an MPEG-TS stream as input? (It looks like it takes an elementary stream, which might kindof work with MPEG-TS because it still has the start codes and can ignore the headers as random garbage, but I wouldn't want to rely on that being sensible at all.)
[16:50:17 CEST] <Zevv> Hi #ffmpeg. I'm porting a desktop app to raspberry; I've built libavcodec with mmal acceleration, which works fine when running with ffmpeg with the cmdline "-vcodec h264_mmal"
[16:50:54 CEST] <Zevv> my app uses probing to find the codec, and does not use the mmal_h264 if a h264 stream is found
[16:51:14 CEST] <Zevv> is there some way to tell libavcodec to use a 'preferred code', or should I just configure the codec manually when the probing detected a h264 stream?
[17:03:12 CEST] <Prelude2004c> jkqxz i wish i knew what it does.. we are pipping the data to it have it transcode and spit the result back out
[17:03:21 CEST] <Prelude2004c> then ffmpeg joins that with the audio and makes it work
[17:03:32 CEST] <Prelude2004c> i take it that it's meant to do that but...
[17:11:24 CEST] <andrey_utkin> this also doesn't result in semi-transparent overlay :( ffplay -f lavfi -i "testsrc=size=1920x1080,format=pix_fmts=yuva420p[bg]; testsrc,format=pix_fmts=yuva420p, geq=lum_expr=lum(X\,Y):cb_expr=cb(X\,Y):cr_expr=cr(X\,Y):alpha_expr=0.5 [overlay]; [bg][overlay]overlay=shortest=1:eval=init"
[17:15:55 CEST] <jkqxz> Prelude2004c: Well, why are you transcoding the video at all there?
[17:22:31 CEST] <andrey_utkin> oh, but this works: ffplay -f lavfi -i "testsrc=size=1920x1080,format=pix_fmts=yuva420p[bg]; testsrc,format=pix_fmts=yuva420p, geq=lum_expr=lum(X\,Y):cb_expr=cb(X\,Y):cr_expr=cr(X\,Y):alpha_expr=0.5*alpha(X\,Y) [overlay]; [bg][overlay]overlay=shortest=1:eval=init" (alpha_expr now includes alpha(), so bare numeric value doesn't work)
[17:31:01 CEST] <Prelude2004c> jkqxz > the video is h264 running at like 8 - 10 Mbit/s.. and i am transcoding back to 720p at 1.8Mbit/s
[17:34:22 CEST] <jkqxz> And you are highly resource-constrained such that using x264 to encode there is not possible? (It would avoid all the multiple processes and nasty piping.)
[17:35:25 CEST] <Prelude2004c> but nvtranscoder only does video right
[17:35:38 CEST] <Prelude2004c> yes i have to use hardware encoding
[17:40:54 CEST] <jkqxz> Reducing the number of variables seems like a sensible move. Can you at least test with x264 in one process (possibly with lower resolution or something if you're on a slow platform) and eliminate the pipes?
[17:41:30 CEST] <TAFB> i need some help with HLS :( I'm using it to stream an 8 hour live stream. I want a 1 hour playlist (so deletes video segments older than one hour and removes them from the playlist). I can't seem to get hls_wrap and hls_list_size set properly. I set them both to 60 but after 1 hour something weird happens were it just keep playing the last video segment, and if I skip back 1 hour, it's playing
[17:41:30 CEST] <TAFB> the new segments?!? lol :(
[17:41:42 CEST] <t4nk978> Hey ;) , is it possible to run FFserver on centos?
[17:41:53 CEST] <t4nk978> it always say "aborted"
[17:43:47 CEST] <TAFB> ahhhhhh hls_flags delete_segments
[17:43:52 CEST] <TAFB> i think that's what I need :)
[19:04:49 CEST] <Justus> hi, I'm looking into screenrecording with ffmpeg, sadly I can't seem to find a way to only record a specific window, all google searches I have managed to come up with just yielded different variations on capturing a screen area. Is it possible to record really only one specific window no matter what is on top of it?
[19:09:26 CEST] <jkqxz> Recording individual windows is possible, but isn't implemented directly in ffmpeg (hacking the xcbgrab input to do it would be straightforward, for example, because it is actually taking part of a window area which currently always happens to be the root window).
[19:10:09 CEST] <jkqxz> The "no matter what is on top of it" part is much harder because areas which are no visible need not be drawn, so the information may just not be there.
[19:10:45 CEST] <zZap-X> Tonights mission: Get my webcam to stream video to nginx-rtmp module using ffmpeg, and making sure video works on IOS and Android
[19:11:23 CEST] <Justus> jkqxz: If I understand it correctly it needs to be supported by the OS, windows actually does so
[19:11:42 CEST] <Justus> jkqxz: but if I understand you correctly there is no way to utilize this currently in ffmpeg?
[19:16:18 CEST] <jkqxz> Screen capture in Windows is all over the place - there are many different ways to do it, all with different deficiencies.
[19:16:52 CEST] <jkqxz> ffmpeg does not attempt to solve any of this problem - there is a simple capture driver which mostly works, and noone has put in the required effort to do better.
[19:18:34 CEST] <zamba> furq: hi again.. are you available to debug my audio sync issues?
[19:20:43 CEST] <furkan> i'm streaming mp3 audio over RTP from a sound system connected to the network, but don't have an SDP file, but FFMPEG seems to be able to correctly "guess" the parameters like the bit rate etc., so is there any way that I can make it generate the SDP file which I can then use with other applications?
[19:22:10 CEST] <zamba> why is a/v sync so incredible hard to get right?
[19:25:54 CEST] <zZap-X> I produced a .mp4 from my webcam using the following: ffmpeg -s 640x480 -f video4linux2 -i /dev/video0 -vcodec h264 test.mp4 It plays on Chrome but does not play in Safari?
[19:48:29 CEST] <pfelt> afternoon all. i'm trying to generate a video of nothing but black using the movie filter. i can't seem to find the right settings when i set filename=/dev/zero for it to actually generate the sequence. anyone know if this is possible?
[19:50:38 CEST] <BtbN> testsrc or something is probably the better choice for that
[19:53:07 CEST] <pfelt> BtbN: there are several other options that work fine. i'm using movie and exposing process_command() in it so that i can change the filename on the fly
[19:53:26 CEST] <pfelt> basically i need movie to just pause reading from a stream without hanging the entire process
[19:54:07 CEST] <BtbN> reading all zeros will most likely be unexpected and cause an error
[19:54:08 CEST] <pfelt> -i would be ideal, but i don't see anywhere that i can actually do what i'm looking for
[19:54:29 CEST] <pfelt> yeah. it does. just wondering if there is some clever way to do it
[19:55:50 CEST] <DHE> API question. I'm trying to encode to x264. It's working, but unless I set tune=zerolatency I get bad frames back. Like only 1/3 to 1/2 the frame is rendered and everything under it is a smudge. playback of the encoded stream shows no decoder errors but it's unwatchable
[19:58:30 CEST] <DHE> setting zerolatency x264 mode renders perfectly
[20:01:49 CEST] <kepstin> could be a frame ordering issue, setting zerolatency tune disables bidirectional predicted frames
[20:04:11 CEST] <zZap-X> wow got it working :D a cross platform mp4
[20:04:35 CEST] <zZap-X> ffmpeg -s 640x480 -f video4linux2 -i /dev/video0 -vcodec h264 -profile:v baseline -level 3.0 -pix_fmt yuv420p test.mp4
[20:04:39 CEST] <zZap-X> works on safari and chrme
[20:05:09 CEST] <kepstin> zZap-X: you don't need the profile or level options, the pix_fmt should be sufficient
[20:05:24 CEST] <zZap-X> aye ok
[20:06:11 CEST] <kepstin> by default if you use screengrab, it's converted to a 4:4:4 yuv mode rather than 4:2:0, and not all decoders can handle that. It should have printed a warning on the console if you're using a recentish ffmpeg
[20:06:55 CEST] <kepstin> hmm, that's not screengrab, that's a webcam, odd.
[20:08:24 CEST] <furq> you need baseline if you want to support really old phones
[20:08:48 CEST] <zZap-X> wow this works too
[20:08:49 CEST] <zZap-X> ffmpeg -s 640x480 -f video4linux2 -i /dev/video0 -vcodec h264 -profile:v baseline -level 3.0 -pix_fmt yuv420p -map 0:0 -f flv -rtmp_buffer 100 -rtmp_live live rtmp://example.org:1935/hls/movie
[20:09:02 CEST] <zZap-X> the rtmp stream works in safari and chrome!
[20:09:07 CEST] <zZap-X> that means it might work on a iphone
[20:09:10 CEST] <furkan> does anybody know how to deal with this error? "Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead."
[20:09:15 CEST] <furkan> i'm googling it and can't find anything
[20:09:55 CEST] <furkan> i'm just running "ffmpeg -f mp3 -i test.mp3 -f rtp rtp://IP:port"
[20:14:05 CEST] <BtbN> by ignoring it
[20:14:10 CEST] <BtbN> unless you are using the api yourself
[20:14:10 CEST] <kepstin> furkan: that's not an error, just a warning, and its target audience is ffmpeg developers not users.
[20:15:59 CEST] <furkan> oh i see, thanks
[20:16:19 CEST] <furkan> ah i get it... i thought it wasn't streaming because i was just getting kicked back to the prompt
[20:16:35 CEST] <furkan> but the file was just so small that it sends the whole thing in an instant
[20:17:02 CEST] <kepstin> if you want to stream a file at 'realtime playback' speeds, you'll want to use the '-re' input option :)
[20:17:18 CEST] <furkan> kepstin: thanks :) any way i can loop it too?
[20:17:47 CEST] <kepstin> furkan: sure. I suggest opening your nearest web browser to the ffmpeg tool docs and giving the old ctrl-f 'loop' a try ;)
[20:18:45 CEST] <zZap-X> the video works on Android!! time to test on Iphone
[20:20:35 CEST] <furq> Justus: https://www.ffmpeg.org/ffmpeg-devices.html#gdigrab
[20:20:44 CEST] <furq> that might do what you want for video, but not for audio
[20:21:40 CEST] Action: kepstin makes no promises that the window selection in gdigrab will actually pick the right window :/
[20:22:07 CEST] <furq> yeah, that's why i said "might"
[20:22:21 CEST] <furq> i seem to recall it's not particularly reliable
[20:22:33 CEST] <furkan> kepstin: haha well i had tried "ffmpeg --help | grep loop" but it looks like not all the options are listed there
[20:22:45 CEST] <furq> furkan: ffmpeg -h full
[20:23:10 CEST] <furkan> furq: wow! thanks haha
[20:24:27 CEST] <pfelt> is it possible to sendcmd to a specific instance of a filter?
[20:25:47 CEST] <furkan> i think there might be a mistake in the documentation? https://ffmpeg.org/ffmpeg.html
[20:25:53 CEST] <furkan> -loop_input
[20:25:55 CEST] <furkan> Loop over the input stream. Currently it works only for image streams. This option is used for automatic FFserver testing. This option is deprecated, use -loop 1.
[20:26:13 CEST] <furkan> but when i try -loop 1 it says "Option loop not found"
[20:26:27 CEST] <furq> i think it was replaced with -stream_loop
[20:26:35 CEST] <furkan> further down there's "stream_loop" yeah
[20:26:42 CEST] <furkan> -stream_loop number (input)
[20:26:44 CEST] <furkan> Set number of times input stream shall be looped. Loop 0 means no loop, loop -1 means infinite loop.
[20:26:54 CEST] <furkan> so i guess that "loop -1" must be wrong
[20:27:12 CEST] <furq> speaking of mistakes in the docs
[20:27:14 CEST] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#mov_002fmp4_002f3gp_002fQuicktme
[20:28:49 CEST] <furkan> i get a "Resource temporarily unavailable" when it tries to loop
[20:28:59 CEST] <furkan> like the file plays the first time, but then when it tries to loop around it fails
[20:29:13 CEST] <furkan> using -stream_loop -1
[20:31:28 CEST] <kepstin> hmm, oh, right, I forgot that the '-loop 1' option is only available on the image2 demuxer :/
[20:31:42 CEST] <kepstin> I'm not sure there is actually a good way to loop arbitrary inputs
[20:32:28 CEST] <kepstin> you can use the 'loop' filter, but that actually buffers all the input frames in ram, iirc :/
[20:36:00 CEST] <furkan> in my case it's just an mp3 file though
[20:36:02 CEST] <furkan> no video
[20:36:52 CEST] <llogan> furq: what's the mistake in that link?
[20:36:59 CEST] <furq> in the title
[20:37:11 CEST] <llogan> ah.
[20:43:23 CEST] <DHE> <kepstin> could be a frame ordering issue, setting zerolatency tune disables bidirectional predicted frames # if I set the GOP setting to 1 (all key frames) I still get this graphical anomaly. that should defeat that, right?
[20:45:42 CEST] <llogan> furq: fixed. thanks.
[20:45:56 CEST] <kepstin> the only other thing i can think of is that maybe some of the buffer memory management isn't write, and you're getting incompletely encoded frames from the multithreaded encoding? That shouldn't happen if you're using the avcodec stuff correctly tho.
[20:45:58 CEST] <llogan> it may take a day for docs to regen
[20:46:40 CEST] <DHE> kepstin: yeah I'm at a loss what's causing this...
[20:58:57 CEST] <explodes> using the library to decode video - i'm using 30% cpu, and a ton of memory
[21:01:01 CEST] <durandal_1707> what video?
[21:22:43 CEST] <DHE> I don't think it's out of order encoding. If I set zerolatency but then enabled bframes it works out
[21:22:53 CEST] <DHE> more experimentation needed
[21:24:18 CEST] <BtbN> did you verify the output actualy has b frames?
[21:26:44 CEST] <DHE> BtbN: yes, ffprobe -show_frames
[21:33:15 CEST] <DHE> I traced it down to a single parameter that affects it: force-cbr. Now I need to figure out what I'm doing wrong that angers x264 in this way
[21:41:19 CEST] <DHE> I think I got it...
[21:45:23 CEST] <Magmatic> Hi everyone. I'm trying to stream from rtp to an icecast server, and I've got it working. Yay! But when I run a second command, listening for rtp on a different port, I get an error.
[21:45:35 CEST] <Magmatic> The error is: bind failed: Address already in use.
[21:46:27 CEST] <Magmatic> The full command I'm running is something like this: ~/bin/ffmpeg -v error -i rtp://192.168.10.16:5801 -legacy_icecast 1 -content_type audio/mpeg -ice_name "Channel1" -f mp3 icecast://source:hackme@example.com:8000/channel1 > /dev/null 2>&1 < /dev/null &
[21:46:35 CEST] <Magmatic> Any ideas?
[21:47:27 CEST] <Magmatic> The second command would look like this: ~/bin/ffmpeg -v error -i rtp://192.168.10.16:5802 -legacy_icecast 1 -content_type audio/mpeg -ice_name "Channel2" -f mp3 icecast://source:hackme@example.com:8000/channel2 > /dev/null 2>&1 < /dev/null &
[21:48:35 CEST] <Magmatic> (I compiled ffmpeg from source a week ago)
[21:51:48 CEST] <furq> Magmatic: try setting -local_rtpport or -local_rtcpport
[21:59:08 CEST] <DHE> thanks for being my rubber duckie
[22:08:16 CEST] <Magmatic> Thanks, furq, for the localrtpport idea, but it's still not working for me.
[22:08:22 CEST] <Magmatic> This is the command I'm running now:
[22:08:53 CEST] <Magmatic> ~/bin/ffmpeg -v error -i rtp://192.168.10.16:5801?localrtpport=5801 -legacy_icecast 1 -content_type audio/mpeg -ice_name "Channel1" -f mp3 icecast://source:hackme@example.com:8000/channel1 > /dev/null 2>&1 < /dev/null &
[22:11:06 CEST] <Magmatic> I still get "bind failed: Address already in use"
[22:24:00 CEST] <explodes> Any reason why "some of the time" the source format in my YUV420p videos would NOT be discovered as YUV420p?
[22:24:38 CEST] <explodes> It's resulting in a SIGABRT in swscale_internal.h: isYUV
[22:29:55 CEST] <furkan> does anybody know how i can tell ffmpeg to only record X number of seconds from an audio stream? over here there's the "aframes" option to set the number of frames, but i'd like to go by duration: http://ffmpeg.org/ffmpeg.html#Audio-Options
[22:32:05 CEST] <kepstin> furkan: you probably want to use the -t option (you can use it as an input option on a specific stream, or as an output option)
[22:33:16 CEST] <furkan> kepstin: thanks i'll give that a try!
[23:17:52 CEST] <Magmatic> I'll answer my own question here.
[23:19:15 CEST] <Magmatic> The reason I was getting a "address already in use" error is because RTP uses two consecutive ports, and I was trying to use bind to the second port as if it were it's own other stream.
[23:33:30 CEST] <zZap-X> how can i stream my webcam from a web gui directly into ffmpeg what is running on the same server?
[23:34:32 CEST] <llogan> what's a web gui?
[23:34:53 CEST] <zZap-X> llogan: like using html5 to access webcam, then send the output to ffmpeg
[23:36:31 CEST] <zZap-X> i guess that would depend on a javascript library what is capable of doing that, i doubt if there is
[23:37:07 CEST] <zZap-X> maybe there is a ffmpeg.hs
[23:37:09 CEST] <zZap-X> maybe there is a ffmpeg.js
[23:43:09 CEST] <fearnothing> hi, having some issues with getting subtitles out, was told you folks might be able to help me
[23:43:29 CEST] <fearnothing> I have some .m4v files ripped with handbrake, and some of them have subtitle tracks
[23:43:51 CEST] <fearnothing> however my media server can't handle the subtitles like that and I've been told to output them to .srt files instead which should work
[23:43:58 CEST] <fearnothing> but when I try to do that, I get an error
[23:44:32 CEST] <fearnothing> "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height"
[23:44:44 CEST] <furq> paste the command line
[23:44:44 CEST] <fearnothing> command is "sudo ffmpeg -i Rashomon.m4v -scodec srt Rashomon.srt"
[23:44:58 CEST] <furq> pastebin the full output as well then
[23:45:08 CEST] <furq> also why are you running that as root
[23:45:36 CEST] <fearnothing> because standard user doesn't have write perms on that directory
[23:47:09 CEST] <fearnothing> https://bpaste.net/show/e45d953dae47
[23:47:48 CEST] <fearnothing> if I try it on a file with no embedded subtitles, it just says the output file is empty
[23:47:53 CEST] <furq> somehow that mp4 file has got dvd subtitles in there
[23:48:07 CEST] <furq> which i didn't even know was possible
[23:48:22 CEST] <furq> -i src.m4v -map 0:3 out.srt
[23:48:24 CEST] <furq> should work
[23:49:09 CEST] <fearnothing> well, I did rip it from a DVD with handbrake
[23:49:26 CEST] <fearnothing> perhaps I used the wrong settings
[23:49:36 CEST] <furq> it has dvd subtitles and text subtitles
[23:49:47 CEST] <furq> so you can just use the text subtitle stream, but you need to select it manually
[23:49:57 CEST] <furq> i just didn't know mp4 could contain picture subtitles
[23:50:07 CEST] <fearnothing> using your command, I got the message that the output file is empty
[23:51:09 CEST] <furq> paste the full output again?
[23:52:01 CEST] <fearnothing> https://bpaste.net/show/4c4f6aa37718
[23:52:17 CEST] <furq> Stream mapping:
[23:52:18 CEST] <furq> Stream #0:3 -> #0:0 (mov_text (native) -> subrip (srt))
[23:52:22 CEST] <furq> that looks correct to me
[23:52:36 CEST] <furq> are you sure the text subtitle stream isn't empty
[23:52:44 CEST] <JEEB> furq: officially it can't but people have hacked them into it
[23:52:51 CEST] <JEEB> aka it's not specified anywhere
[23:52:53 CEST] <furq> i suspected as much when i saw "handbrake"
[23:53:03 CEST] <JEEB> I'm pretty sure it's not the only thing that lets you do that
[23:53:20 CEST] <JEEB> and handbrake is probably one of the less retarded encoding GUIs out there
[23:53:35 CEST] <furq> handbrake is all right but i know it does some weird shit sometimes
[23:54:12 CEST] <fearnothing> if I play the m4v in VLC, I have 3 subtitles options: 'Track 1 [English]', 'Track 3' and 'Track 3 [English]'
[23:54:15 CEST] <JEEB> GPAC also I think supports the vobsub-in-mp4 thing, not sure if it was originally brought out by nero in their ripping software
[23:54:38 CEST] <JEEB> nero is also the place to thank for the non-MOV style chapters in mp4
[23:54:43 CEST] <furq> fearnothing: can you actually see the text subtitles
[23:55:02 CEST] <fearnothing> Track 1 [English] shows the subtitles correctly
[23:55:12 CEST] <fearnothing> the other two show nothing, and the chapter number, respectively
[23:55:58 CEST] <furq> sounds like the text track is empty then
[23:56:23 CEST] <fearnothing> makes sense... where do I find the actual subtitles then?
[23:56:46 CEST] <furq> track 1 is the actual subtitles but you'll need to convert them with some OCR tool
[23:57:01 CEST] <fearnothing> @_o
[23:57:04 CEST] <furq> i've not done that in years so someone else can probably recommend a decent tool
[23:57:09 CEST] <llogan> or maybe find them online if the timing fits
[23:57:16 CEST] <furq> yeah that can be easier
[23:57:21 CEST] <fearnothing> can't I just rip the DVD again with some other options?
[23:57:27 CEST] <furq> dvd subtitles are images
[23:57:39 CEST] <furq> any method of ripping them to text involves OCR
[23:57:52 CEST] <fearnothing> d'oh
[23:58:11 CEST] <furq> that's why they look blocky and horrible
[23:58:31 CEST] <fearnothing> ok, so I think this is something that will affect more than one of my movies
[23:58:40 CEST] <furq> does your media player play mkv
[23:58:47 CEST] <fearnothing> yes
[23:58:47 CEST] <furq> it might have better luck with dvd subtitles in mkv
[23:58:55 CEST] <furq> since it's not officially supported in mp4
[23:59:06 CEST] <fearnothing> it's plex media server
[23:59:09 CEST] <fearnothing> if that helps
[23:59:14 CEST] <furq> try ffmpeg -i src.m4v -c copy out.mkv
[00:00:00 CEST] --- Thu Apr 14 2016
1
0
[04:23:11 CEST] <cone-498> ffmpeg 03Michael Niedermayer 07master:196cfc278d2b: avformat/utils: use av_codec_g/set_lowres()
[05:05:38 CEST] <rcombs> looks like somebody at apple accidentally &'d a `const void*` to pass it to as an arg of the same type in AudioToolbox
[11:00:59 CEST] <omerjerk> hey, so I've a 32 bit integer. uint32_t return_val;
[11:01:10 CEST] <omerjerk> I need to assign the bits of this to a float.
[11:01:32 CEST] <omerjerk> And I'm doing it like this - float tmp = *(float*) &return_val;
[11:01:54 CEST] <omerjerk> but when I compile, the compiler gives out the warning - warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
[11:02:16 CEST] <omerjerk> So, I wanted to ask is there any other util function available in ffmpeg to do what I'm doing ?
[11:02:41 CEST] <jkqxz> memcpy()
[11:03:06 CEST] <wm4> aren't there libavutil functions for this
[11:03:44 CEST] <wm4> intfloat.h
[11:04:23 CEST] <omerjerk> Thanks jkqxz. I totally forgot about that.
[11:04:32 CEST] <omerjerk> wm4: let me have a look.
[11:05:30 CEST] <omerjerk> oh yes.
[11:05:32 CEST] <omerjerk> there is av_int2float
[11:05:32 CEST] <cone-755> ffmpeg 03Paul B Mahol 07master:9149e9c0baae: avcodec/apedec: fix decoding of stereo files with one channel full of silence
[11:05:33 CEST] <omerjerk> thanks.
[11:05:35 CEST] <omerjerk> I'll use it.
[11:13:05 CEST] <BtbN> that sounds odd, what is that needed for?
[13:39:48 CEST] <wm4> found a site that hosts broken mkv files produced by libavformat as "samples for testing": http://www.sample-videos.com/
[13:40:12 CEST] <JEEB> lol
[13:40:58 CEST] <wm4> | + Name: ENCODER at 617
[13:40:58 CEST] <wm4> | + String: Lavf53.24.2 at 627
[14:08:35 CEST] <nevcairiel> how broken are they
[14:09:25 CEST] <wm4> both the 1MB and 50MB samples start with negative timestamps (like -2 seconds for video), the 50MB one doesn't have an index entry for the start of the video
[14:09:38 CEST] <nevcairiel> well 53 is ages ago
[14:10:12 CEST] <nevcairiel> no index for timestamp 0 is oddly enough a common enough problem
[14:10:29 CEST] <nevcairiel> luckily also easily enough remedied in a demuxer
[14:10:56 CEST] <wm4> haven't seen many of such cases
[14:11:13 CEST] <wm4> my favorite broken file is one that has no packets flagged as key frames (produced by lavf of course)
[14:11:23 CEST] <wm4> and libavformat has a hack to handle such files
[14:11:28 CEST] <wm4> which also breaks seeking in valid files
[14:11:41 CEST] <wm4> I should send a patch to revert that
[14:34:42 CEST] <Daemon404> what is the use of this mastering metadata for mkv anyway
[14:34:47 CEST] <Daemon404> archiving?
[14:35:33 CEST] <wm4> not sure
[14:36:14 CEST] <wm4> I'm confused about how it's set/exported though
[14:36:41 CEST] <Daemon404> it's also not spec-final
[14:36:57 CEST] <wm4> that patch seems like quite a horrible way to make it settable from ffmpeg CLI
[14:37:21 CEST] <Daemon404> yes
[14:51:29 CEST] <nevcairiel> its the same ugly syntax x265 cli uses
[14:52:04 CEST] <nevcairiel> but yeah presumably its for storing hdr video where this info isnt in the bitstream, ie part of CELLAR I assume
[14:52:14 CEST] <nevcairiel> but the spec was not finished
[14:52:22 CEST] <Daemon404> hmm neat i see marton ported ffplay
[14:52:26 CEST] <Daemon404> \o/
[14:52:35 CEST] <nevcairiel> the patch looks trivial enough as well
[14:52:38 CEST] <Daemon404> yea
[14:53:00 CEST] <nevcairiel> looks like it still used st->codec before, but it kept a reference in another struct
[14:53:07 CEST] <nevcairiel> which made creating a new context for it trivial
[14:53:11 CEST] <Daemon404> right
[14:53:18 CEST] <Daemon404> im working on ffprobe today
[14:53:27 CEST] <Daemon404> ive already merged antons initial changes requried to support codecpar
[14:53:30 CEST] <Daemon404> and they worked fine
[14:53:44 CEST] <Daemon404> some stuff in ffprobe will be under deprecation guards
[14:53:49 CEST] <Daemon404> liek codec_time_base
[14:54:41 CEST] <Daemon404> it doesnt look too hard though
[14:54:44 CEST] <Daemon404> seems only ffmpeg.c will be
[15:49:35 CEST] <Daemon404> almost done ffprobe
[15:49:36 CEST] <Daemon404> - "codec_time_base": "1/25",
[15:49:36 CEST] <Daemon404> + "codec_time_base": "1/51200",
[15:49:41 CEST] <Daemon404> only thing i have left to fix
[15:49:47 CEST] <Daemon404> (this is under deprecation guards)
[15:50:38 CEST] <Daemon404> i dont know if this is fixable, since it no longer uses st->codec to decode
[15:51:29 CEST] <Daemon404> oh.. hmm think i might know
[15:51:39 CEST] <wm4> wth. is codec_time_base
[15:52:25 CEST] <Daemon404> hmm nope
[15:52:31 CEST] <Daemon404> wm4, i have been askign this for YEARS
[15:52:49 CEST] <Daemon404> and yeah i cant figure out how to 'fix' this output
[15:52:49 CEST] <nevcairiel> its the fps in the bitstream, if any
[15:53:01 CEST] <Daemon404> nevcairiel, this is a nut file with rawvideo
[15:53:04 CEST] <Daemon404> it doesnt bloody have one
[15:53:22 CEST] <nevcairiel> nut is special, it stores this value somewhere
[15:54:01 CEST] <nevcairiel> you could add a hack under deprecation guards to assign your decode context time_base from st->codec
[15:54:23 CEST] <nevcairiel> or just accept it
[15:54:31 CEST] <Daemon404> the decode context timebase is 0/1
[15:54:33 CEST] <Daemon404> when i print it
[15:54:49 CEST] <nevcairiel> how did it work before then
[15:54:59 CEST] <Daemon404> i have no idea
[15:56:53 CEST] <Daemon404> everything else in ffprobe is working
[15:57:02 CEST] <Daemon404> i saw libav just completely removed codec_time_base printing
[15:57:12 CEST] <Daemon404> i'd prefer that too but people would bitch
[15:57:25 CEST] <Daemon404> although those people would almost certainly be using ffprobe wrong
[15:59:33 CEST] <Daemon404> would it help if i pasted my WIP patch
[16:11:20 CEST] <Daemon404> GRRRR
[16:11:24 CEST] <Daemon404> ffmpeg.org is down again
[16:11:29 CEST] <Daemon404> 2nd day i na row
[16:11:42 CEST] <Daemon404> or rather extremely slow
[16:12:10 CEST] <Zeranoe> After some testing I found that a MinGW build of FFmpeg is roughly 25% faster than a MSVC one of the same version. I don't know if this is due to pthreads vs w32threads, but I did find the initial results interesting...
[16:13:02 CEST] <Daemon404> that depends masisvely on which codec
[16:13:09 CEST] <Zeranoe> mpeg4 in this case
[16:13:43 CEST] <Zeranoe> And why does it massively depend on the codec?
[16:14:02 CEST] <Daemon404> because msvc does not have inline asm
[16:14:07 CEST] <Daemon404> and only some codecs use it
[16:14:34 CEST] <jamrial> Zeranoe: how does pthreads/w32threads relate to this? you can use either of the two with mingw
[16:15:25 CEST] <Zeranoe> jamrial: Because the MinGW build used pthread and the MSVC used w32thread. I don't know the speed comparison between the two
[16:15:59 CEST] <Daemon404> nevcairiel, ugh
[16:16:01 CEST] <Daemon404> //err = avcodec_parameters_to_context(ist->dec_ctx, stream->codecpar);
[16:16:04 CEST] <Daemon404> err = avcodec_copy_context(ist->dec_ctx, stream->codec);
[16:16:06 CEST] <Daemon404> ^ fixes codec_time_base output
[16:16:08 CEST] <Daemon404> but pure WTF
[16:16:20 CEST] <Daemon404> something sure is funky
[16:16:38 CEST] <Zeranoe> Daemon404: inline ASM might be a clue. Do you know a codec that would be a fair comparison?
[16:18:40 CEST] <jamrial> then just compile with mingw + w32threads to make a (maybe) fairer comparison
[16:19:08 CEST] <nevcairiel> mpeg4 is riddled with inline asm, thats expected
[16:19:24 CEST] <nevcairiel> with h264 the comparison shrinks, but gcc builds are still faster
[16:19:55 CEST] <nevcairiel> w32threads dont really cost you performance
[16:21:34 CEST] <Daemon404> nevcairiel, i figured it out
[16:21:50 CEST] <Daemon404> st->codec->framerate wasnt copied when creating a new stream context
[16:21:58 CEST] <Daemon404> this somehow makes its way to time_base later
[16:21:59 CEST] <Daemon404> a bit wtf
[16:22:07 CEST] <Daemon404> guess ill add taht copy under deprecation guards
[16:23:30 CEST] <Zeranoe> I was considering providing MSVC builds, but I don't really see the benefit if it's so much slower
[16:23:57 CEST] <Daemon404> Zeranoe, the only benefits are being able to debug in msvc's debugger, and static linking with msvc projects
[16:24:15 CEST] <Zeranoe> Debugging was the main drive
[16:24:38 CEST] <Zeranoe> But I don't think it offsets that performance gap
[16:25:10 CEST] <nevcairiel> people that want to debug build their own builds
[16:25:29 CEST] <Daemon404> you would think so... but...
[16:25:37 CEST] <Daemon404> a lot of people just dl Zeranoe's build and link to it
[16:25:40 CEST] <Daemon404> (usually illegally)
[16:25:52 CEST] <Zeranoe> Or complain to me about wanting a MSVC build
[16:25:58 CEST] <Zeranoe> then build it themselves
[16:26:23 CEST] <Zeranoe> This is also why I don't provided static libs
[16:28:42 CEST] <Daemon404> wm4, ping. did you add these: gaplessinfo-itunes1 / gaplessinfo-itunes2
[16:28:48 CEST] <wm4> no
[16:28:54 CEST] <Daemon404> damn ok
[16:29:16 CEST] <Daemon404> one frame changed info when i converted ffprobe.c
[16:29:20 CEST] <Daemon404> -frame|pkt_pts=2112|pkt_dts=2112|best_effort_timestamp=2048|pkt_duration=960|nb_samples=960
[16:29:23 CEST] <Daemon404> +frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=960
[16:29:55 CEST] <wm4> maybe the timestamp adjustment code is disabled due to not setting pkt_timebase?
[16:30:18 CEST] <Daemon404> ah pkt_timebase...
[16:30:48 CEST] <Daemon404> i can add a copy for that under deprecation guards... but... eh...
[16:30:59 CEST] <Daemon404> should i really need to copy from st->codec? is it too dumb?
[16:31:29 CEST] <wm4> pkt_timebase should be the same as the AVStream timebase
[16:31:39 CEST] <wm4> because it's the timebase packet timestamps use
[16:32:02 CEST] <Daemon404> ah.. good
[16:32:10 CEST] <Daemon404> in this new model of ffprobe, each stream has its own decoder context
[16:32:13 CEST] <Daemon404> so it should be doable
[16:32:41 CEST] <Daemon404> yes using that fixes it
[16:33:40 CEST] <Daemon404> fate all passes now
[16:38:29 CEST] <cone-755> ffmpeg 03Anton Khirnov 07master:ba357e98691e: avprobe: switch to codecpar
[16:38:30 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:9080dc7f0742: Merge commit 'ba357e98691ee4fe1a503b8830c0050be4127475'
[16:39:29 CEST] <cone-755> ffmpeg 03Anton Khirnov 07master:dbb43b8b83b0: avpacket: properly reset data/size in av_packet_move_ref()
[16:39:30 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:9a98ddcf1b30: Merge commit 'dbb43b8b83b097585ec255ec638b61e359ebea77'
[16:42:02 CEST] <cone-755> ffmpeg 03Luca Barbato 07master:ce9d7da76504: qsv: Move down the implementation query
[16:42:03 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:6e2ca814857b: Merge commit 'ce9d7da7650473f580dcce8c9f8550ea532aa6bd'
[16:42:43 CEST] <cone-755> ffmpeg 03Diego Biurrun 07master:73ff983e8dd2: fft: x86: cosmetics: Drop silly comments, add comment, whitespace
[16:42:44 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:d496d52d029a: Merge commit '73ff983e8dd22ccee166403d0bbbc9c1cd543622'
[16:43:19 CEST] <cone-755> ffmpeg 03Diego Biurrun 07master:97aec6e75ef3: fft: arm: Drop unnecessary #include, add missing ones
[16:43:20 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:197fa698c6cf: Merge commit '97aec6e75ef36ed0402653519daa8e1fc8ddb555'
[16:45:03 CEST] <cone-755> ffmpeg 03Diego Biurrun 07master:4c297249ac0f: rdft: arm: Split RDFT initialization into a separate file
[16:45:04 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:2605967f7eb5: Merge commit '4c297249ac0f513a610a62691ce96d6b62f65b94'
[16:58:28 CEST] <cone-755> ffmpeg 03Diego Biurrun 07master:f6ccee9bed92: fate: fft: Split DCT/FFT/MDCT/RDFT tests into separate targets
[16:58:29 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:05e4783c2910: Merge commit 'f6ccee9bed92c09799777c1dfb2b2772763e0e83'
[16:59:58 CEST] <cone-755> ffmpeg 03Mark Harris 07master:4d13bcceb9a1: sdp: fix opus sprop-stereo fmtp syntax
[16:59:59 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:aa9517583ea1: Merge commit '4d13bcceb9a1820f8e9b2c89e00816d3db41b716'
[17:11:31 CEST] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=1a094af638281295bf087945923d2… <-- barf
[17:12:04 CEST] <Daemon404> gonna be a pita
[17:12:55 CEST] <nevcairiel> thats diego in a nutshell =p
[17:12:56 CEST] <BBB> as long as theres two projects, every major refactoring in them is a pain for us
[17:13:07 CEST] <BBB> Id almost say that thats the whole summary of their existence
[17:13:07 CEST] <Daemon404> this isnt major
[17:13:13 CEST] <Daemon404> its just annoying
[17:13:18 CEST] <Daemon404> i wouldnt. just diego's.
[17:13:19 CEST] <BBB> stop merging it
[17:13:29 CEST] <BBB> stop merging diegos commits
[17:13:38 CEST] <Daemon404> then every actual useful commit becomes 100x harder to merge
[17:14:11 CEST] <durandal_1707> what don touched this time?
[17:14:47 CEST] <Daemon404> the refactoring is actually more correct, in this case
[17:15:38 CEST] <durandal_1707> oh looks like lot of work
[17:15:47 CEST] <kierank> why does he want to extract fft from mdct
[17:15:56 CEST] <nevcairiel> dont ask why diego does things
[17:15:58 CEST] <nevcairiel> he just does
[17:17:20 CEST] <BBB> michaelni: in ffh264, Im looking at stuff like MB_TYPE_PnLn where n is 0 or 1 (in {b,p{,_sub}}_mb_type_info) - what does the P stand for?
[17:28:21 CEST] <Daemon404> BBB, i think having to rescale with swscale is a problem with ffmpeg.c, not individual muxers
[17:28:26 CEST] <Daemon404> re: framehash
[17:28:40 CEST] <BBB> I thought that got fixed in ffmpeg.c?
[17:28:56 CEST] <BBB> I recall discussing that with michaelni a while ago and theres a way for ffmpeg.c to not force rescaling of all frames to the same size
[17:29:46 CEST] <nevcairiel> i think the problem is that rawvideo doesn't really have a way to signal resolution changes to a rawvideo muxer
[17:29:57 CEST] <nevcairiel> since it has no frame-level metadata
[17:30:20 CEST] <nevcairiel> you could try to use the wrapped_avframe dealy, maybe that allows it
[17:35:13 CEST] <michaelni> BBB, IIRC P stands for partition
[17:35:14 CEST] <jkqxz> BBB: Pn is the partition being referred to by the particular element? (PxLy - partition x uses reference list y, etc.) Those appear to be tables 7-11 to 7-18 in H.264.
[17:35:35 CEST] <jkqxz> Not sure how that is mapping to four-partition macroblocks, though.
[17:35:35 CEST] <BBB> so why is it only p0 and p1 even in case of split (pcnt=4)?
[17:36:44 CEST] <michaelni> the case for 4 is handled differently in the bitstream and data structures
[17:37:23 CEST] <BBB> I see, ok
[17:37:37 CEST] <Daemon404> damn, crash with converted ffprobe...
[17:37:40 CEST] <Daemon404> debuggin
[17:37:57 CEST] <BBB> each 8x8 subblock can have different refs, but each 4x4 uses the same refs within the parent 8x8, right?
[17:38:07 CEST] <BBB> (or 4x8, or 8x4)
[17:38:24 CEST] <michaelni> IIRC yes
[17:38:38 CEST] <BBB> ty
[17:46:51 CEST] <rcombs> Daemon404: regarding autobsf+dash, what would you recommend I do? Have the mov muxer turn autobsf off at init-time?
[17:50:35 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:9cb1ed5735ec: ffprobe: Fix missing dec_ctx check
[17:52:47 CEST] <nevcairiel> rcombs: dont they need to set some common attribute for dash behavior to be enabled, that you could check for?
[17:53:11 CEST] <rcombs> nevcairiel: they set movflags=+dash
[17:53:30 CEST] <rcombs> well, strictly, they set movflags=frag_custom+dash+delay_moov
[17:53:44 CEST] <rcombs> not sure if one of those is more productive to gate this on than dash itself
[17:53:59 CEST] <rcombs> and I'm assuming that nobody will ever want auto-bsf at the mov muxer level when using DASH
[17:54:17 CEST] <rcombs> (in my patches, autobsf works at the DASH muxer level)
[18:24:45 CEST] <cone-755> ffmpeg 03Derek Buitenhuis 07master:e8373143e118: ffprobe: Don't try and decode things that have no dec_ctx
[18:35:55 CEST] <kurosu> Zeranoe: mpeg-2, xvid or vp9 - h264/avc or hevc are particularly hindered by bitstream reading using gcc inline asm
[18:36:38 CEST] <Daemon404> mpeg-2 has a bunch of inline asm
[18:36:58 CEST] <kurosu> oh right, some mc functions I haven't converted
[18:37:10 CEST] <kurosu> (not sure they impact much the decoding, but true)
[18:37:22 CEST] <Daemon404> i seem to recall quit a difference
[18:37:27 CEST] <Daemon404> but this was ~2 years ago
[18:37:28 CEST] <Daemon404> or 3
[18:38:49 CEST] <kurosu> also, the mastering metadata effort is indeed probably linked to HDR
[18:44:53 CEST] <wm4> does anyone know how HDR is supposed to work yet?
[18:46:01 CEST] <Daemon404> kurosu, BBC/EBU/whoever is doing a separate type of HDR btw
[18:46:09 CEST] <Daemon404> 'backwards compatible'
[18:46:20 CEST] Action: Daemon404 is sure it till be fun to mix
[18:46:55 CEST] <kurosu> then you have hdr10, then dolby vision
[18:47:12 CEST] <kurosu> (or the reverse, as netflix will initially use the later)
[18:47:28 CEST] <Daemon404> excellent. so many choices. /s
[18:48:33 CEST] <kurosu> Wait for Google's own version
[18:48:53 CEST] <kurosu> it's as if ffmpeg will soon need improved colorspace filters <g>
[18:49:06 CEST] <kierank> hdr is a joke
[18:49:12 CEST] <kierank> can only see the difference in the dark by the water
[18:49:20 CEST] <kierank> another geek toy like 4k
[18:50:17 CEST] <kurosu> kierank, wait until you have to implement part of it for your clients :p
[18:50:35 CEST] <Daemon404> his clients will probably want the easy one (ebu)
[18:50:36 CEST] <kierank> they need to be able to deliver it to me in a cable first
[18:50:47 CEST] <Daemon404> kierank, good thing the ebu one can!
[18:50:51 CEST] <kierank> the easy one I do nothing
[18:50:54 CEST] <durandal_1707> BBB: when you gona apply filter?
[18:51:02 CEST] <kierank> actually I got asked to implement the dolby one
[18:51:06 CEST] <kierank> but nobody gave me a spec
[18:51:11 CEST] <Daemon404> kierank, depends if it needs special processing wrt color stuff they need
[18:51:14 CEST] <Daemon404> but yea
[18:51:19 CEST] <durandal_1707> buy spec
[18:51:26 CEST] <kierank> spec don't exist
[18:51:27 CEST] <Daemon404> you cant buy dolby specs
[18:55:40 CEST] <kurosu> http://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-white-pap… <- Dolby Vision seems to be based on some sort of scalable coding (p11)
[18:56:12 CEST] <kurosu> oh, and multiview hevc/avc-based
[19:03:35 CEST] <rcombs> kurosu: Daemon404: wtf is dolby vision anyway
[19:03:52 CEST] <rcombs> I've got a sample file here and afaik it's lust an hevc 10-bit file?
[19:04:36 CEST] <JEEB> yeah, it should be standard 10bit HEVC with specific mastering data
[19:04:50 CEST] <JEEB> and then possibly some specs on the playback side
[19:04:54 CEST] Action: JEEB shrugs
[19:05:10 CEST] <rcombs> wow, they're not even developing their own mediocre tech anymore
[19:05:16 CEST] <rcombs> just slapping their name on existing stuff
[19:05:18 CEST] <JEEB> I linked stuff on the video type of "HDR" for a guy before
[19:05:20 CEST] <rcombs> I think that's a plus
[19:05:53 CEST] <JEEB> but yeah, basically content-wise it's just that mastering metadata crap
[19:05:58 CEST] <JEEB> and then it gets rendered accordingly
[19:07:01 CEST] <rcombs> dialnorm for video!
[19:07:16 CEST] <rcombs> I'm sure it'll be used just as effectively in practice
[19:11:55 CEST] <wm4> well what the consumer sees is that the video is "faded"
[19:12:07 CEST] <haasn> the answer is everybody does HDR differently. it's all marketing
[19:12:19 CEST] <haasn> no standard at all
[19:12:29 CEST] <haasn> Or well, no consistent use of the existing standards
[19:12:38 CEST] <kierank> what existing standrads
[19:13:28 CEST] <haasn> SMPTE ST-2084
[19:13:32 CEST] <Daemon404> why even do real hdr. just crank up the contrast and saturation and tell people it's hdr
[19:13:35 CEST] <Daemon404> they eat it up
[19:14:01 CEST] <fritsch> :-)
[19:14:03 CEST] <fritsch> so true
[19:14:12 CEST] <fritsch> sadly
[19:14:40 CEST] <Daemon404> add some bloom for good measure
[19:15:24 CEST] <rcombs> I mean, 10-bit coding can be useful for efficiency and handling dark gradients and such well
[19:15:40 CEST] <fritsch> yes ... but it's not only the decoder
[19:15:44 CEST] <fritsch> but the rendering, the display
[19:16:09 CEST] <fritsch> on linux intel gpus cannot even output 10 bit colors
[19:16:18 CEST] <wm4> yet?
[19:16:22 CEST] <haasn> bit depth and HDR are not strictly related. The difference is in the semantics. You can get 10 and 12-bit coding for traditional response curves that max out at 120 cd/m². In fact, BT.2020 standardizes those exact two bit depths
[19:16:37 CEST] <fritsch> wm4: i think plain X works, but in combination with OpenGL big problem
[19:16:38 CEST] <Daemon404> fritsch, who even owns 10bit panels
[19:16:40 CEST] <haasn> HDR is not just adding bits, it's taking the 120 cd/m² peak and raising it up to 10,000 cd/m²
[19:16:44 CEST] <rcombs> clearly we should compromise at either 9-bit or 11-bit
[19:16:44 CEST] <Daemon404> aside from a very select group
[19:16:49 CEST] <rcombs> this will solve all the problems
[19:16:56 CEST] <haasn> Daemon404: who even owns 8bit panels
[19:16:57 CEST] <kierank> haasn: that's essentially dolby
[19:16:58 CEST] <haasn> aside from a very select group
[19:17:05 CEST] <kierank> 2804
[19:17:07 CEST] <Daemon404> lol... somewhat true
[19:17:14 CEST] <Daemon404> 8bit is becoming somewhat more common though
[19:17:17 CEST] <haasn> I mean most 10 bit displays on the market are 8 bit panels with good dithering
[19:17:21 CEST] <wm4> fritsch: that's terrible
[19:17:28 CEST] <haasn> and 8 bit displays on the market are mostly 6 or 7 bit panels with dithering
[19:17:39 CEST] <wm4> fritsch: I think the same works perfectly well on dxva/d3d11
[19:17:51 CEST] <rcombs> my laptop's 8-bit :3
[19:17:56 CEST] <haasn> meanwhile it took nvidia a few years to get 10-bit support implemented after announcing the feature
[19:17:59 CEST] <rcombs> pretty sure my projector is too
[19:17:59 CEST] <haasn> but now it works
[19:18:11 CEST] <rcombs> (3LCD lol)
[19:19:48 CEST] <fritsch> wm4: most likely, yes
[19:19:54 CEST] <BBB> durandal_1707: can do now if you want
[19:19:56 CEST] <haasn> anyway the problem with Ultra HD and BT.2020 in general is that there's a lot of standards confusion going on; because the idea of the standard was to support a very gratuitous color space, suitable for virtually any future media - except apparently nobody really talked about how people would actually use it on real world displays that can't perfectly reproduce these ideals
[19:20:00 CEST] <BBB> durandal_1707: I dont tihnk there were any pending big comment
[19:20:48 CEST] <haasn> for example, how would you watch a BT.2020 wide gamut film on a TV that can only handle adobeRGB gamut. How do you watch a HDR movie with super-peaks at 5000 cd/m² on a TV that only goes up to 1000 (or 100)
[19:21:13 CEST] <haasn> The standards are built around unrealistic ideal devices
[19:22:03 CEST] <haasn> Which is fine in theory but in practice nobody can seem to agree about how to use them. Do you just encode movies with a limited range (as a subset of the available encoding space) so that real world devices can display them? What devices do you target?
[19:22:07 CEST] <nevcairiel> there are algorithms to compress the gamut or luminance
[19:22:42 CEST] <haasn> Yeah but these algorithms generally require the ability to know what the signal peak is going to be (ahead of time)
[19:22:53 CEST] <haasn> for example, what brightness do you map onto the display's maximum?
[19:23:17 CEST] <nevcairiel> if its a SDR display thats pretty easy
[19:23:28 CEST] <haasn> One solution would be sufficiently tagging this information so you can pick a good-enough conversion algorithm, but such tagging seems to be absent
[19:23:31 CEST] <nevcairiel> and HDR should have metadata to tell you the peak
[19:23:45 CEST] <nevcairiel> at least h265 hdr encoders do have it
[19:23:49 CEST] <haasn> It doesn't in practice (from what I've seen)
[19:24:01 CEST] <nevcairiel> any hevc hdr samples i have seen have it
[19:24:09 CEST] <haasn> interesting, got some examples?
[19:24:18 CEST] <haasn> or sample files that I could use for testing
[19:24:21 CEST] <nevcairiel> at least those that claim to be uhd blu-ray hdr compatible
[19:24:29 CEST] <haasn> (and does ffmpeg export this information?)
[19:24:40 CEST] <nevcairiel> on an API level its exported now
[19:24:46 CEST] <nevcairiel> not sure how well the CLI shows it
[19:24:56 CEST] <Daemon404> re metadata: "iirc, contains the primaries, transfer curve, and peak brightness of the reference display"
[19:25:00 CEST] <Daemon404> from elsewhere
[19:25:08 CEST] <Daemon404> seems relevant (peak brightness)
[19:25:32 CEST] <nevcairiel> people have implemented hdr -> sdr conversion algorithms based on that metadata, and it looks better than a sdr source of the same content =p
[19:25:36 CEST] <haasn> What is this primaries tag? Is that the signal peak, or is that just tagging whether it's BT.2020 or BT.709 or whatever?
[19:26:09 CEST] <nevcairiel> http://demo-uhd3d.com/fiche.php?cat=uhd&id=89 .. that sample should have all the data iirc
[19:26:20 CEST] <nevcairiel> other hdr samples on that site as well, but one or two were broken
[19:26:31 CEST] <haasn> nevcairiel: Mapping HDR to SDR during display and just encoding the SDR sample that way to begin with are technically indistinguishable. My guess is that it just looks different, new, exciting, and therefore better
[19:26:45 CEST] <haasn> Like the I bought new headphones and everything sounds so amazing now effect
[19:27:45 CEST] <nevcairiel> well not quite, authoring from the original master could result in a different image
[19:28:01 CEST] <haasn> There is two version of this demo (Right Clic and Save) and I don't realy know what's the difference (only 1Kb difference ...) : lol
[19:28:19 CEST] <nevcairiel> unfortunately HDR -> SDR conversions dont seem to be standardized yet
[19:28:34 CEST] <fritsch> amlogic does it blackbox wise ...
[19:28:49 CEST] <fritsch> on linux, they decode and then directly output to framebuffer
[19:28:52 CEST] <nevcairiel> wonder what (if anything) future SDR TVs might do for UHD HDR playback
[19:29:10 CEST] <haasn> nevcairiel: How long did it take the ITU-R to standardize HDR -> SDR conversion (on the dark end of the spectrum) last time? :p
[19:29:34 CEST] <haasn> (that is going from a color space with a true black point to a display with a low contrast)
[19:30:12 CEST] <fritsch> dark channel prior for the win
[19:30:31 CEST] <fritsch> though ... that won't work as it will end up as contrast maximization
[19:30:34 CEST] <fritsch> for every image
[19:40:47 CEST] <jamrial> BBB: example of wrapped_avframe vs rawvideo: http://pastebin.com/raw/uVEqJ6UK
[19:41:15 CEST] <nevcairiel> wrapped avframe should probably hash the contents, not the frame itself
[19:55:34 CEST] <cone-755> ffmpeg 03Moritz Barsnick 07master:f4a0236cbd75: avformat: add hash and framehash muxers
[19:55:35 CEST] <cone-755> ffmpeg 03Michael Niedermayer 07master:e3111b1ff859: avformat/framehash: Add more information to the output
[20:21:31 CEST] <cone-755> ffmpeg 03James Almer 07master:d7815df40285: arm/rdft_init: fix license header
[20:21:47 CEST] <blop> hello ;)
[20:22:25 CEST] <blop> is it possible to disable audio decoding while using -acodec copy ? ffmpeg keeps trying to decode AAC and fail, but all I need is copy
[20:29:03 CEST] <JEEB> that should not decode the audio at all
[20:29:35 CEST] <JEEB> blop: and please don't spam both channels :P for such usage questions the main channel works
[20:29:43 CEST] <blop> yes sorry :)
[20:29:47 CEST] <JEEB> so please respond there with the command line and terminal output pastebin'd
[20:30:30 CEST] <wm4> JEEB: it may decodes some by libavformat design
[20:30:41 CEST] <JEEB> sure
[20:30:44 CEST] <JEEB> for probing
[20:41:33 CEST] <DHE> as I understand it ffmpeg does decode just enough to identify the stream, for metadata purposes. once it's ready the stream copy does not decode
[20:41:53 CEST] <DHE> avformat_find_stream_info does this
[20:41:59 CEST] <JEEB> the errors happen after the probing
[20:42:12 CEST] <JEEB> http://pastebin.com/dWc9THSS
[21:49:14 CEST] <durandal_1707> working on libnut codecpar changes?
[21:50:27 CEST] <wm4> who cares about libnut
[22:15:09 CEST] <Angus> is anyone here familar with the H264_vdpau codec/decoder?
[22:15:31 CEST] <fritsch> ask your questions and we will see if you get responses
[22:16:04 CEST] <Angus> If you call avcodec_decode_video2 with the codec initialized to h264_vdpau, does it work?
[22:16:29 CEST] <Angus> this guy:
[22:16:30 CEST] <Angus> http://stackoverflow.com/questions/23289157/how-to-use-hardware-acceleratio…
[22:17:07 CEST] <Angus> seem to have run into a bunch of problems with the vdpau decoder, although I'm not sure if he was using avcodec_decode_video2
[22:23:30 CEST] <jkqxz> Angus: Standalone H.264 vdpau decoder ("h264_vdpau") is deprecated but still in the codebase. You want to use the normal decoder + vdpau hwaccel.
[22:25:28 CEST] <jkqxz> (ffmpeg_vdpau.c being an example of what you need to do to set that up.)
[22:26:45 CEST] <Angus> would avcodec_decode_video2 still be used in that case? I suspect I would have to write a function to replace it?
[22:27:06 CEST] <fritsch> why?
[22:28:13 CEST] <jkqxz> Yes. You use it with the decoder "h264", and have a suitable hwaccel_context in the AVCodecContext.
[22:30:36 CEST] <Angus> ahh, I see. Would the decoder .capabilities need to be updated for hwaccel?
[22:32:07 CEST] <Angus> (with AV_CODEC_CAP_HWACCEL_VDPAU )
[22:38:18 CEST] <jkqxz> No? That looks like it exists to hack the standalone decoder into working. (It's inside deprecation markers, anyway.)
[22:41:06 CEST] <BBB> kierank: with the clipw addressed, ok to commit colorspace filter?
[22:41:20 CEST] <BBB> kierank: I agree the constants should be grouped in lavfi, Ill do that separtately since it involves quite a few filters
[22:41:35 CEST] <BBB> kierank: theres no constants in lavfi yet...
[22:41:38 CEST] <kierank> Ok
[22:41:40 CEST] <wm4> Angus: ffmpeg_vdpau.c might serve as example
[22:41:41 CEST] <BBB> ty
[22:41:42 CEST] <kierank> Ok
[22:41:46 CEST] <wm4> Angus: it has all of the glue code needed
[22:42:41 CEST] <Angus> alright, going to read through it more carefully then
[22:43:28 CEST] <cone-755> ffmpeg 03Ronald S. Bultje 07master:2e2e08a35b47: lavfi: new colorspace conversion filter.
[22:43:29 CEST] <cone-755> ffmpeg 03Ronald S. Bultje 07master:5ce703a6bff7: vf_colorspace: x86-64 SIMD (SSE2) optimizations.
[22:44:57 CEST] <durandal_1707> now we can deprecate colormatrix shit
[22:46:19 CEST] <wm4> ok so we have 4 filters which can do conversions and also a library nobody wants to cleanup
[22:56:02 CEST] <cone-755> ffmpeg 03Paul B Mahol 07master:392b0a25c236: avcodec/exr: fix clearing end of bitmap
[22:56:03 CEST] <cone-755> ffmpeg 03Martin Vignali 07master:ac07e57c39de: avcodec/exr: fix huf_decode
[22:59:47 CEST] <durandal_1707> wm4: moar features
[22:59:53 CEST] <cone-755> ffmpeg 03Yuuki Galaxy 07master:af5419f91b06: libavfilter/vf_owdenoise.c: skip processing when strength is 0
[23:32:30 CEST] <michaelni> BBB, "vf_colorspace: x86-64 SIMD (SSE2) optimizations." break checkasm here
[23:32:41 CEST] <BBB> hm?
[23:32:44 CEST] <BBB> works for me
[23:32:59 CEST] <BBB> got more details?
[23:33:05 CEST] <michaelni> "Bus error" here valgrind says:
[23:33:12 CEST] <michaelni> Process terminating with default action of signal 11 (SIGSEGV)
[23:33:12 CEST] <michaelni> ==29432== Access not within mapped region at address 0x7FF001000
[23:33:13 CEST] <michaelni> ==29432== at 0x4210EE: rgb2yuv_444p10_c (colorspacedsp_template.c:187)
[23:33:13 CEST] <michaelni> ==29432== by 0x41F65A: checkasm_checked_call (checkasm.asm:242)
[23:33:28 CEST] <michaelni> beynd that the backtrace is bunch of ???
[23:33:50 CEST] <nevcairiel> my msvc fate box also segfaults on it
[23:33:58 CEST] <BBB> 32bit or 64bit?
[23:34:02 CEST] <nevcairiel> 32
[23:34:07 CEST] <michaelni> 64 here
[23:34:09 CEST] <BBB> that should never run any assembly
[23:34:13 CEST] <BBB> very confused
[23:34:28 CEST] <Daemon404> his bt looks like the c path.
[23:34:40 CEST] <BBB> oh I see
[23:34:53 CEST] <BBB> I think were overallocating the rgb buffer by 2x and underallocating the yuv buffer by 2x
[23:34:54 CEST] <BBB> clever
[23:35:47 CEST] <nevcairiel> and that didnt crash for you?
[23:35:54 CEST] <BBB> michaelni: in checkasm/vf_colorspace.c line 206-215, can you change the buf size of uint8_t buffers from W * H to W * H * 2, and int16_t buffers from W * H * 2 to W * H?
[23:36:00 CEST] <BBB> nope, runs fine for me
[23:36:33 CEST] <nevcairiel> guess windows actually cares to check memory access then =p
[23:36:50 CEST] <BBB> I think it simply means array layout on stack is inverted for clang
[23:37:11 CEST] <BBB> (dst is locates before src)
[23:37:26 CEST] <BBB> which means we overwrite dst into src, but since both c and asm paths do that, the outcome is actually still identical
[23:37:57 CEST] <BBB> nevcairiel: or you can test that change also if you want
[23:38:15 CEST] <BBB> my tree is quite messy so itd take me a while to submit a patch (working on some h264 stuffies)
[23:38:29 CEST] <michaelni> BBB works with the change
[23:38:30 CEST] <nevcairiel> thats what git invented stash for =)
[23:38:40 CEST] <BBB> Ive never used stash in my life
[23:38:53 CEST] <BBB> quilt had push/pop, is it similar to that?
[23:38:59 CEST] <JEEB> yeah
[23:39:04 CEST] <BBB> ah, ok
[23:39:07 CEST] <JEEB> git stash pushes, git stash pop pops
[23:39:07 CEST] <BBB> intruiging
[23:39:18 CEST] <BBB> should look into that
[23:39:25 CEST] <JEEB> that said, I always tend to forget about what I had in git stash if it's for more than 10 seconds
[23:39:32 CEST] <JEEB> so I just use branches with quick commits
[23:40:08 CEST] <michaelni> BBB should i push the *2 change or you do it (asking as "my tree is quite messy so itd take me a while to submit a patch") ?
[23:40:16 CEST] <BBB> you can do it, thanks
[23:40:30 CEST] <JEEB> but it's simple for git stash && git merge origin/master && git stash pop or so, where I just want to remove and re-add some changes that I haven't committed
[23:40:31 CEST] <BBB> I suppose wed want this in quickly
[23:40:44 CEST] <michaelni> k, ill just test on other platforms too
[23:43:05 CEST] <BBB> ty
[23:45:50 CEST] <cone-755> ffmpeg 03Marton Balint 07master:ee94b1a50ad9: ffplay: convert to codecpar
[23:48:01 CEST] <cone-755> ffmpeg 03Michael Niedermayer 07master:4d59d075a96c: tests/checkasm/vf_colorspace: Fix dst array sizes
[00:00:00 CEST] --- Wed Apr 13 2016
1
0
[03:12:27 CEST] <FlorianBd> Hi there! When extracting pictures using -r 0.1 for example, is there a way to apply an rgb level range to it? e.g. I want the output to be from 8 to 180 instead of 0 to 255.
[03:12:49 CEST] <FlorianBd> so it's like RGB curves but total linear
[03:12:52 CEST] <FlorianBd> totally
[03:16:23 CEST] <FlorianBd> hmm I think I found :) -filter_complex 'colorlevels=aomin=0.0353:aomax=0.706' correct?
[03:24:04 CEST] <Yay295> Hello. Just wondering, if I did "crop=iw:ih:0:0", does ffmpeg know to ignore that option?
[03:33:56 CEST] <FlorianBd> ok so no, that does not work: -filter_complex 'colorlevels=aomin=0.0353:aomax=0.706'
[03:48:19 CEST] <FlorianBd> AHHH ok, a is alpha of course... so if I want all channels I need to specify all r, g and b
[04:12:06 CEST] <kepstin> Yay295: it'll still have some overhead because it still has to go through the crop filter. The crop filter is ridiculously fast anyways, so I wouldn't worry
[04:12:41 CEST] <kepstin> (crop filter doesn't actually copy or modify any video data, it just changes buffer metadata like offset, stride, line count, row count)
[04:18:06 CEST] <Yay295> Okay, thanks.
[09:39:00 CEST] <Thor________> hi, anyone know if ffmpeg can act as a RTPM server ?
[09:59:29 CEST] <pfelt> evening all. i'm trying to generate a 2x2 grid (using [hv]stack) of udp based streams. i'm having a heck of a time trying to find a way to enable me to change what is being displayed on one of the grid items without having to restart the entire process. i'd like to be able to kill one of the udp feeds on the source side and not have ffmpeg croak
[09:59:40 CEST] <pfelt> anyone have any ideas on how to do this?
[10:02:58 CEST] Action: pfelt is having a hard time understanding why this is so difficult
[15:03:39 CEST] <KevinA> Hello, I'm trying to build the latest FFMPEG on windows using VS2015. I've had success with VS2013 before. My config is ./configure --toolchain-msvc --enable-shared --arch=i386
[15:04:54 CEST] <KevinA> It configures fine. When I type make I get a message """Make: *** No rule to make target `libavdevice/avdevice.dll', needed by `all-yes`. Stop"""
[15:05:30 CEST] <KevinA> If i enable-static. I fails to link swscale
[16:45:36 CEST] <vanila> hello
[16:45:53 CEST] <vanila> what is the fastest way to take screenshots of various times in a video?
[16:56:21 CEST] <TheGreatDoc> Hi all
[16:58:12 CEST] <TheGreatDoc> I finally have working ffmpeg to udp multicast. Now I have a little problem with the decklink card
[16:58:39 CEST] <TheGreatDoc> If the input fails and come up again, I have to reset the ffmpeg
[16:59:22 CEST] <TheGreatDoc> Also, would be awesome if the input fails, ffmpeg shows an image and when input comes back start streaming the input again
[17:20:14 CEST] <Yo[x]> Hello, Trying to install kdenlive but can't add any video clip due to library codec problem. ffmpeg and libav are involved in this problem. I got this result with avplay video playing test : http://pastebin.com/u2gzd29W. I don't know where i have to go to find a way to solve this issue. thanks for any help.
[17:41:00 CEST] <DHE> I'm trying to follow the source code examples for decoding video. I have successfully opened an MPEG2 decoder and got back a 1920x1080 AVFrame, but the AVCodecContext that goes with it still has codec->width and codec->height unset. How do those get set? I'm using examples/transcoding.c open_input_file() as a starting point
[17:55:54 CEST] <Yo[x]> ok sorry. forget my question. It's work with mplayer using ffmpeg/libav decoder. So issue is not from ffmpeg/libav
[17:57:23 CEST] <DHE> regarding my issue, as far as I can tell avformat_find_stream_info is supposed to provide this but it's not...
[17:59:57 CEST] <newbie_ffmpeg> Hi all, I am trying to add a cross fade to a video of 1 second each. http://pastebin.com/AG3UJguT The input and the output are present here.
[18:00:33 CEST] <newbie_ffmpeg> The problem is that the output framerate etc is different from the input
[18:00:55 CEST] <newbie_ffmpeg> Is there a way for me to get the same characteristics as the input videos when adding the cross fade?
[18:16:20 CEST] <kepstin> newbie_ffmpeg: I don't know if it would help, but you don't need to use a lavfi input with the color filter; you can include it in a filter_complex string directly.
[18:16:56 CEST] <kepstin> (and the color filter takes a framerate of the video it generates as an option - this should be set to match the input streams)
[18:17:11 CEST] <newbie_ffmpeg> <kepstin> Can you please show me an example?
[18:17:15 CEST] <kepstin> you might want to normalize all the videos to the exact same framerate e.g. with the fps filter.
[18:18:14 CEST] <kepstin> -filter_complex 'color=black:s=1280x720:r=30[black]; ... rest of filter chain ...'
[18:18:28 CEST] <kepstin> where you can then use [black] as an input to another filter
[18:18:57 CEST] <newbie_ffmpeg> <kepstin> Thanks I will try that!
[18:44:47 CEST] <DHE> yeah, I try to use the example transcoding.c sample and the codec parameters (width, height) etc are filled in. I try with my code which is functionally similar but I get nothing in those fields, but I do get coded_width/height set.
[18:54:33 CEST] <DHE> oh I'm an idiot... I found out what's wrong.. miscompilation
[19:00:06 CEST] <pikaro> hi! I'd like to use ffmpeg to record from ALSA with as little a gap as possible. for that, a python script terminates the previous ffmpeg process and immediately starts a new one. this is apparently too rapid as I get "device busy" errors. at what point does the device get freed by ffmpeg? is waiting for the process to terminate reliable enough? or is this more of an alsa question, i. e. does the device maybe stay busy after ffmpe
[19:00:06 CEST] <pikaro> g exits?
[20:03:23 CEST] <zamba> which connection gives the best quality: composite or s-video?
[20:04:41 CEST] <zamba> oh.. looks like it's s-video
[20:10:30 CEST] <DHE> RF < composite < s-video < component < HDMI
[20:17:31 CEST] <zamba> i so didn't know that
[20:18:15 CEST] <zamba> how much difference is there in practice between s-video and composite?
[20:21:29 CEST] <blop> hello ;)
[20:22:28 CEST] <blop> is it possible to disable audio decoding while using -acodec copy ? ffmpeg keeps trying to decode AAC and fail, but all I need is copy
[20:23:26 CEST] <c_14> Not that I know of, and don't post user questions in #ffmpeg-devel
[20:24:00 CEST] <c_14> You might want something like mp4box or mkvtoolnix or l-smash
[20:24:04 CEST] <c_14> Something that only remuxes
[20:24:31 CEST] <blop> ok thanks :) i will give a try at those
[20:26:01 CEST] <furq> zamba: that's not really easy to quantify
[20:26:13 CEST] <furq> it's significant enough that you should be able to tell the difference
[20:26:36 CEST] <furq> although things like cable quality will make a difference
[20:28:42 CEST] <zamba> when using ffmpeg to capture from the device, how can i select s-video as input?
[20:29:03 CEST] <furq> there are some comparison videos on youtube but they all seem to be of games consoles
[20:29:25 CEST] <furq> and i imagine that depends on your capture device
[20:30:02 CEST] <JEEB> blop: here I mean :P
[20:30:05 CEST] <blop> yes
[20:32:37 CEST] <blop> JEEB : I'm trying to copy an encrypted mpeg-ts stream (for recording purpose). If I use -an it's working as expected, but I need to preserve audio of course. And ffmpeg is detecting aac audio channels and try to decode them. Then I have tons of "AAC bitstream not in ADTS format and extradata missing" and finally a "AAC packet too short" followed by "av_interleaved_write_frame(): Invalid data found when processing input"
[20:33:32 CEST] <JEEB> blop: pastebin full command line and terminal output. although I guess it fails even before it starts doing anything
[20:33:33 CEST] <blop> all streams are mapped as "(copy)" but somehow it tries to decode the AAC inputs (which fails because it's encrypted)
[20:33:47 CEST] <JEEB> I want to check how it exactly fails
[20:34:58 CEST] <blop> for example http://pastebin.com/dWc9THSS
[20:35:47 CEST] <JEEB> and same happens with straight-up mpeg-ts output as well?
[20:35:59 CEST] <llogan> zamba: how are you going from device to ffmpeg? what type of device is it?
[20:36:26 CEST] <blop> JEEB: yes it fails with a plain.ts file too
[20:36:47 CEST] <JEEB> as in output, right?
[20:36:53 CEST] <blop> yes
[20:37:47 CEST] <blop> with only: ffmpeg -i udp://239.192.5.46:7092 -c copy -sn out.ts
[20:37:51 CEST] <JEEB> might be trying to parse rather than decode...
[20:38:02 CEST] <blop> yes maybe
[20:38:13 CEST] <JEEB> because remuxing is after all demux and remux
[20:39:17 CEST] <blop> i don't get why it needs to parse the audio channels :)
[20:39:44 CEST] <zamba> llogan: i believe it's an easy cap dc-90
[20:39:46 CEST] <blop> using -an fix the issue, no more warning/errors
[20:40:45 CEST] <zamba> llogan: i use -f video4linux2 with ffmpeg, but it seems to be fixed on composite input
[20:40:50 CEST] <JEEB> blop: because it's needed to correctly mux the stream again I would think :) if you can demux and then remux without doing that, then sure
[20:41:15 CEST] <JEEB> in that case ffmpeg.c or libavformat is doing non-required stuff
[20:41:25 CEST] <JEEB> in which case a bug report + a short sample would be in place
[20:41:42 CEST] <JEEB> (it's encrypted so I'd guess it'd be relatively easily provide'able)
[20:42:19 CEST] <zamba> llogan: for mencoder/mplayer it's said to use :input=X to specify which input to use, but i'm not able to do that with ffmpeg, as far as i can tell?
[20:42:25 CEST] <blop> JEEB: i guess it's trying to parse too much yes. The stream is encrypted using a mainstream DRM system and is remuxable by some professional appliance
[20:42:44 CEST] <Raiz> ffmpeg is complaining about missing codecs, where I can find those?
[20:42:48 CEST] <blop> i will open a bug report tomorrow ;)
[20:42:53 CEST] <JEEB> yeah, if remuxing is done on a more high level
[20:43:03 CEST] <llogan> zamba: does the device not have a switch on it to select which one to use?
[20:43:17 CEST] <JEEB> basically take the stream and don't even try to touch it. of course that doesn't let you remux to other containers
[20:43:33 CEST] <JEEB> which is what the ffmpeg.c's remuxing does
[20:43:47 CEST] <zamba> llogan: nope
[20:43:47 CEST] <JEEB> it effectively strips things out of the container, then puts them into another
[20:43:54 CEST] <furq> Raiz: which codecs
[20:44:11 CEST] <zamba> llogan: i believe this is done in the kernel module
[20:44:15 CEST] <Raiz> I want to convert an mp4 to ogg file
[20:44:16 CEST] <zamba> llogan: or by the application
[20:44:17 CEST] <JEEB> the fact that input and output containers match in this case don't cause any simpler code path to be used :)
[20:44:35 CEST] <Raiz> it's codec theora
[20:44:36 CEST] <JEEB> I'm actually thinking of making something that remuxes limited streams, too
[20:44:51 CEST] <JEEB> because I have a need for limiting streams that go through
[20:44:56 CEST] <JEEB> so PMT and things have to be rewritten
[20:45:08 CEST] <JEEB> but the actual PIDs' contents can be kept as-is
[20:45:15 CEST] <blop> :)
[20:45:25 CEST] <furq> Raiz: -c:v libtheora
[20:45:36 CEST] <furq> assuming you actually want to keep the video
[20:46:04 CEST] <furq> if that's missing then you need to recompile ffmpeg or install a binary with libtheora included
[20:46:06 CEST] <Raiz> unknowing encoder: libtheora :(
[20:46:17 CEST] <blop> i will provide a sample input.ts with the bug report. I know it's a strange use case, but ffmpeg should also be usable strictly as a remuxer :)
[20:46:26 CEST] <Raiz> sigh
[20:46:34 CEST] <furq> do you actually want to convert the video or just the audio
[20:47:11 CEST] <Raiz> I download music from utube and I want to get rid of the video part of them and leave them as audio files
[20:47:17 CEST] <furq> use -vn then
[20:47:34 CEST] <zamba> llogan: yup, i can do it with mencoder and :input=1 passed
[20:47:34 CEST] <Raiz> for what format I'd convert that?
[20:47:41 CEST] <furq> i wouldn't convert it at all
[20:47:49 CEST] <Raiz> mp4 without video?
[20:47:52 CEST] <furq> -i src.mp4 -vn -c:a copy dest.m4a
[20:48:06 CEST] <Raiz> that's m4a
[20:48:19 CEST] <furq> well yeah that's what i would do
[20:48:29 CEST] <furq> if you specifically want ogg then -i src.mp4 -vn dest.ogg
[20:48:35 CEST] <furq> that'll reencode to vorbis
[20:48:46 CEST] <furq> if you don't need to do that then you shouldn't because you'll lose quality
[20:49:00 CEST] <Raiz> converted it to wav :D
[20:49:39 CEST] <furq> well i guess at least that doesn't lose quality
[20:49:54 CEST] <Raiz> video quality or audio quality?
[20:50:17 CEST] <furq> which do you think
[20:50:21 CEST] <Raiz> audio
[20:50:24 CEST] <furq> hooray
[20:50:25 CEST] <blop> JEEB: thank you for your help ;)
[20:50:42 CEST] <furq> i have no idea what situation you're in where you can use wav or ogg but not aac
[20:50:47 CEST] <furq> but ok
[20:51:04 CEST] <Raiz> trying ogg
[20:51:12 CEST] <Raiz> but what did the -vn option do?
[20:51:18 CEST] <furq> no video
[20:51:55 CEST] <Raiz> it's better now, it's a chiptune so quality is not a big deal
[20:52:18 CEST] <furq> dare i ask what chiptune
[20:52:43 CEST] <llogan> zamba: you can see what is available with ffmpeg -f v4l2 -list_formats all -i /dev/video0
[20:52:55 CEST] <llogan> or "v4l2-ctl --list-formats-ext"
[20:52:58 CEST] <Raiz> 4-mat - rose
[20:53:31 CEST] <furq> you know ffmpeg has libmodplug support, right
[20:53:38 CEST] <Raiz> nope
[20:54:57 CEST] <furq> http://api.modarchive.org/downloads.php?moduleid=157314#4-mat_-_rose.xm
[20:55:02 CEST] <furq> well now you can convert it in a less ridiculous way
[20:55:11 CEST] <furq> or just listen to the xm
[20:55:33 CEST] <Raiz> I use ffplay to run video/audio, can it read xm files?
[20:56:20 CEST] <furq> if it was compiled with libmodplug support then sure
[20:57:20 CEST] <furq> you should probably use a non-debug video player like mpv though
[20:58:01 CEST] <Raiz> since ffplay comes with ffmpeg and all the codecs, why would I install more software :P
[20:58:11 CEST] <furq> because ffplay is a really bad video player
[20:58:29 CEST] <Raiz> I was using mplayer in the past
[20:58:36 CEST] <thebombzen> furq: ffplay is great for certain uses
[20:58:51 CEST] <JEEB> ffplay is a proof of concept / example kind of thing. if it works for you, great. but don't expect it to have good rendering or anything like that
[20:59:12 CEST] <furq> yeah it's good for debugging but not much else
[20:59:18 CEST] <JEEB> mpv is probably the least retarded child of the mplayer family, both on *nix as well as on windows or OS X
[20:59:21 CEST] <Raiz> what you use then?
[20:59:24 CEST] <furq> mpv uses the ffmpeg libs
[20:59:34 CEST] <furq> and is generally more usable and looks much nicer
[20:59:51 CEST] <thebombzen> if you're looking for a video player that works best, I'd use mplayer but make sure you compile it against ffmpeg and not libav
[20:59:56 CEST] Action: JEEB actually had fun getting mpv running on android, too
[21:00:16 CEST] <furq> obviously if you're on windows then mpc-hc is the ultimate king
[21:00:19 CEST] <JEEB> thebombzen: recommending mplayer instead of any more maintained fork? color me surprised!
[21:00:22 CEST] <JEEB> furq: not really
[21:00:33 CEST] <JEEB> mpv has windows as a first class citizen
[21:00:44 CEST] <JEEB> opengl renderer works with d3d through ANGLE
[21:00:49 CEST] <JEEB> and there's a wasapi audio renderer
[21:00:49 CEST] <furq> i know, i have it installed
[21:00:52 CEST] <furq> i still prefer mpc-hc
[21:01:09 CEST] <JEEB> I've worked with mpc-hc and DirectShow for years
[21:01:11 CEST] <furq> it sucks for streaming, though
[21:01:13 CEST] <JEEB> and I just can't take it any more
[21:01:20 CEST] <thebombzen> JEEB: sorry if I'm missing sarcasm here, but mplayer is maintained
[21:01:20 CEST] <furq> what's wrong with it
[21:01:28 CEST] <thebombzen> there was a minor release two months ago
[21:01:31 CEST] <JEEB> thebombzen: *more* maintained
[21:01:34 CEST] <furq> other than where you just said "directshow" obviously
[21:01:43 CEST] <JEEB> mplayer does have one or two guys kind of poking at it
[21:01:58 CEST] <JEEB> furq: the UI is OK but I'm just getting tired of all the issues related to DShow
[21:01:58 CEST] <thebombzen> in that case, what is *more* maintained than mplayer? i.e. which player should I be using instead
[21:02:03 CEST] <Raiz> okay, will try mpv
[21:02:09 CEST] <furq> thebombzen: mpv
[21:02:14 CEST] <JEEB> you should be using whatever you have decided to be best for you
[21:02:24 CEST] <JEEB> mpv is the most maintained mplayer fork currently
[21:02:26 CEST] <thebombzen> right, which was mplayer, and I decided that based on limited knowledge
[21:02:40 CEST] <thebombzen> if mpv is essentially mplayer then I'll probably use that
[21:02:53 CEST] <thebombzen> first I'll have to rebuild git master of ffmpeg though, I'm a bit overdue on that ;-)
[21:02:56 CEST] <JEEB> mpv was forked off a fork of mplayer with various improvements and clean-ups
[21:03:03 CEST] <furq> i like the fact that nobody has yet recommended vlc
[21:03:07 CEST] <furq> long may it continue
[21:03:14 CEST] <JEEB> I use VLC for non-playback usage
[21:03:27 CEST] <thebombzen> haha vlc can't use libass on linux. really annoying
[21:03:36 CEST] <JEEB> huh, it can just fine
[21:03:40 CEST] <furq> i occasionally use it for streaming, but mpv seems to be just as good for that
[21:04:21 CEST] <thebombzen> JEEB: really? I built vlc 3.0.0 from git recently and it says "unrecognized codec ID" and references the streams with the TTF/OTF font files
[21:04:29 CEST] <thebombzen> whereas mplayer can just, render it fine
[21:04:36 CEST] <JEEB> that's not up to libass really
[21:04:51 CEST] <JEEB> and I don't think the fonts are streams, they're supposed to be attachments
[21:05:04 CEST] <thebombzen> you're right, they are. mispoke
[21:05:05 CEST] <JEEB> if you have muxed in OTF or TTF as a stream, then congratulations :P
[21:05:11 CEST] <thebombzen> I mean, vlc can't just render ASS subs the way mplayer can.
[21:05:17 CEST] <thebombzen> it just errors and makes me sad
[21:05:21 CEST] <thebombzen> unless I"m doing it wrong
[21:05:24 CEST] <JEEB> it should be able to, at least when I tested :P
[21:05:26 CEST] <thebombzen> it does on Windows though, which is weird
[21:05:35 CEST] <JEEB> because you don't build that yourself most probably
[21:05:49 CEST] <thebombzen> no, the VLC from the repos also can't
[21:05:57 CEST] <thebombzen> I built it myself because I thought it would fix that
[21:06:02 CEST] <JEEB> then something funky's going on around that :P
[21:06:07 CEST] <thebombzen> clearly
[21:06:21 CEST] <JEEB> there can be a VLC bug but that would then affect all OSs
[21:06:42 CEST] <JEEB> anyways, I've only used VLC on android for playback lately (until I got my mpv-android thingy going)
[21:06:49 CEST] <JEEB> and otherwise it's a useful tool for other things
[21:06:54 CEST] <JEEB> I don't even build it with GUI :)
[21:50:19 CEST] <thebombzen> wow that's a big update to ffprobe
[21:52:08 CEST] <JEEB> well dae and nev et al just got The Evil Plan 2 improvements merged into FFmpeg from Libav
[21:52:27 CEST] <JEEB> ffprobe I think got updated for that earlier today
[21:55:20 CEST] <Milardo> Hi i have a question about ffmpeg video filter in the documentation "9.57 framerate"
[21:55:54 CEST] <Milardo> i have heard this filter can be used for motion interpolation
[21:56:22 CEST] <Milardo> Im not sure exactly about the options of it though
[21:56:45 CEST] <kepstin> it doesn't really do motion interpolation, it just blends (crossfades) between two frames.
[21:56:50 CEST] <Milardo> like interp_start and interp_end and scene?
[21:57:57 CEST] <Milardo> so it has nothing to do with it and no matter how i tweak the options, it wont make my video have motion interpolation?
[22:00:26 CEST] <thebombzen> I have a question myself now - sometimes there's animations at 24 fps but for fairly unintensive graphics, parts of it will only be 8 fps - i.e. every three frames are the same.
[22:00:31 CEST] <thebombzen> if I reduce the framerate from 24 fps to 12 fps with "-r", it will appear choppy because every other frame will be duplicated (2 and 3 are relatively prime).
[22:00:40 CEST] <thebombzen> is there a way to make it less choppy? will -vf framerate do the trick, even though I'm reducing the framerate by an integer amount?
[22:00:43 CEST] <durandal_1707> no motion interpolation, yet
[22:01:14 CEST] <Milardo> no filter yet for it in ffmpeg?
[22:05:39 CEST] <kepstin> thebombzen: huh, I don't think I've seen 8fps animations in 24fps video before. No way around that if you use the fps filter (or -r option), but you might be able to play with the 'mpdecimate' filter to get the effect you want.
[22:06:13 CEST] <thebombzen> kepstin: some animes will do that in scenes that are just characters talking. no reason to move the mouth at 24fps
[22:06:31 CEST] <kepstin> anime is animated at 12fps by standard, then frame-doubled to 24
[22:06:39 CEST] <kepstin> 8fps is very rare in it :/
[22:07:39 CEST] <kepstin> I suppose in some really slow bits where they are running out of budget and/or time, you could see 8fps :/
[22:08:33 CEST] <kepstin> There's usually very little reason to bother changing the framerate from 24 (actually 24000/1001), since the video codec will compress the duplicate frames well anyways.
[22:09:02 CEST] <thebombzen> true. inter-prediction is pretty good.
[22:09:34 CEST] <kepstin> but if you really want to remove them, something like the 'mpdecimate' filter will take them out without changing the frame timing, so you get 24fps video with a bunch of skip frames instead of duplicate frames.
[22:10:18 CEST] <kepstin> (or variable framerate output, basically)
[22:12:03 CEST] <Milardo> no filter for motion interpolation in ffmpeg yet?
[22:12:57 CEST] <zamba> llogan: but this doesn't say anything about which input that's going to be used?
[22:14:56 CEST] <zamba> this is the output if i add -loglevel 99: [video4linux2,v4l2 @ 0x4d47340] Current input_channel: 0, input_name: Composite1, input_std: ffffff
[22:15:06 CEST] <zamba> so i basically need to change input_channel to 1
[22:15:14 CEST] <furq> Milardo: there are avisynth/vapoursynth plugins which will do it
[22:15:34 CEST] <Milardo> yes i have seen that
[22:16:09 CEST] <furq> zamba: -channel 1 (maybe)
[22:16:23 CEST] <furq> https://www.ffmpeg.org/ffmpeg-devices.html#Options-17
[22:19:56 CEST] <zamba> that worked.. thanks :)
[23:08:39 CEST] <zamba> hm.. seems like my system is not able to encode two streams in realtime
[23:40:01 CEST] <petecouture> zamba: multi bitrate?
[23:40:15 CEST] <zamba> petecouture: what do you mean by multi?
[23:40:40 CEST] <petecouture> Nm
[23:40:51 CEST] <petecouture> You can encode a single stream to different bitrates
[23:40:55 CEST] <petecouture> for live broadcasting
[23:41:06 CEST] <zamba> oh.. no.. this is different sources
[23:41:07 CEST] <petecouture> Dunno if that's what you ment
[23:41:15 CEST] <petecouture> Gotcha
[23:51:54 CEST] <petecouture> For a live input/output streams, if the bandwidth of the input drops, what's the flag to have the encoder kept encoding the last frame over and over again so it doesn't pause encoding waiting for packets to arrive?
[23:55:58 CEST] <kepstin> ffmpeg doesn't really have anything like that
[23:57:10 CEST] <llogan> the usual once weekly question of how to show static image or another video when another one is unavailable
[23:58:58 CEST] <petecouture> llogan: No I think that's async protocol you're thinking off. I'm trying to make it so that the encoder won't crap out if it hasn't received RTP packets for a while.
[23:59:59 CEST] <petecouture> kepstin: I could have sworn there was something that the encoder will continue processing 'dead air' as filler so the timemark is maintained
[00:00:00 CEST] --- Wed Apr 13 2016
1
0
[00:05:19 CEST] <kierank> should I demand a vote for this faac thing
[00:23:28 CEST] <durandal_170> kierank: you can, but voting may never happen as next meeting is not going to happen, it appears..
[00:32:22 CEST] <atomnuker> pointless, by then we'll have a fast enough aac coder
[00:38:30 CEST] <jamrial> durandal_170: i'm fairly sure voting can be done on the ml
[00:38:53 CEST] <Daemon404> i have yet to see anything go to a vote
[00:41:53 CEST] <atomnuker> no need to make a fuss out of it, it's not that much work to make a fast coder with an RC
[00:42:41 CEST] <nevcairiel> how much performance does one gain by disabling all the feautres like MS, PNS, TNS?
[00:45:21 CEST] <atomnuker> not much, most actually increase the performance (1/2 coeffs for IS, no coeffs for PNS)
[00:45:52 CEST] <atomnuker> though figuring out when to use PNS overweights the performance benefit there
[00:45:53 CEST] <nevcairiel> i thought it might do some extra analysis to see if its worth using that might be skipped and therefor faster
[00:46:21 CEST] <atomnuker> quantization isn't particularly fast
[01:35:12 CEST] <cone-277> ffmpeg 03Michael Niedermayer 07master:02d08da81fd8: avdevice/caca: switch to codecpar
[04:35:25 CEST] <cone-854> ffmpeg 03Michael Niedermayer 07master:4104f1835851: avformat/segment: Pass flags to child context
[04:35:25 CEST] <cone-854> ffmpeg 03Michael Niedermayer 07master:0c9ad94e97ba: avformat/dashenc: Pass flags to child context
[04:35:25 CEST] <cone-854> ffmpeg 03Michael Niedermayer 07master:15fa01786ce6: avformat/hdsenc: Pass flags to child context
[04:44:07 CEST] <jamrial> 25k fps, lol
[06:24:05 CEST] <rcombs> jamrial: SMOOOOOOOOOOTH
[11:36:16 CEST] <durandal_1707> michaelni: your fix for shorten is wrong for valid files
[11:36:41 CEST] <durandal_1707> bitshift can be 32
[12:33:54 CEST] <ubitux> oh, codecpar merged
[12:34:00 CEST] <ubitux> thanks everyone
[12:34:20 CEST] <ubitux> Daemon404: so do you need help now with monkey merging?
[12:35:10 CEST] <ubitux> btw, unrelated but i have all kind of off by ones error in fate-rv20-1239 with aarch64 (under qemu at least)
[12:35:11 CEST] <durandal_1707> its valid to shift int by 32?
[12:35:19 CEST] <ubitux> but the instance on fate doesn't seem to have that issue
[12:35:41 CEST] <ubitux> durandal_1707: which direction?
[12:35:55 CEST] <durandal_1707> left
[12:36:21 CEST] <ubitux> if the int is negative, left shift is undefined
[12:37:23 CEST] <nevcairiel> which means it still works everywhere we know of
[12:38:15 CEST] <ubitux> we need more aarch64 fate instances :(
[12:38:30 CEST] <durandal_1707> it gives 0?
[12:38:44 CEST] <jkqxz> Left shifting int by 32 is undefined because some architectures mask to only the relevant bits (so it's << 0) and some don't.
[12:43:24 CEST] <rcombs> strictly that depends on the size of int :P
[12:44:02 CEST] Action: rcombs defines an ABI where int is 8-byte, just because we needed more complexity in our lives
[12:44:30 CEST] <rcombs> but hey at least shifting int left by 32 bits would be well-defined there
[12:44:31 CEST] Action: nevcairiel hires a guy for some good old fashioned "wet work"
[12:44:47 CEST] <iive> rcombs: if you want more complexity, try 16bit char
[12:45:04 CEST] <rcombs> iive: so 16-bit bytes?
[12:45:14 CEST] <nevcairiel> no, only chars
[12:45:18 CEST] <iive> i didn't say that :P
[12:45:22 CEST] <rcombs> iirc C defines sizeof(char) == 1
[12:45:34 CEST] <rcombs> but doesn't define how many bits in a char
[12:46:38 CEST] <JEEB> yeah
[12:47:02 CEST] <rcombs> `CHAR_BIT`
[12:48:03 CEST] <rcombs> oh apparently it's guaranteed to be _at least_ 8 bits, since `signed char` must be "Capable of containing at least the [127, +127] range"
[12:48:12 CEST] <JEEB> aj
[12:48:13 CEST] <JEEB> ah
[13:08:08 CEST] <Daemon404> ubitux, yea sure. lets see how far i get today.
[13:22:03 CEST] <cone-985> ffmpeg 03Paul B Mahol 07master:b62ed56e25c8: avcodec/shorten: properly handle bitshift > 31
[13:44:08 CEST] <ubitux> the fuck is wrong with this fate-rv20-1239 test :(
[14:04:16 CEST] <nevcairiel> lowres be evil
[14:07:10 CEST] <wm4> ubitux: ?
[14:07:32 CEST] <ubitux> it fails on aarch64 here, dunno why
[14:07:38 CEST] <ubitux> all kind of off-by-one
[14:07:54 CEST] <ubitux> it predates codecpar merge afaict
[14:18:29 CEST] <Daemon404> ubitux, well at least thats good to know :)
[14:19:12 CEST] <wm4> lowres for realvideo sure is important
[14:20:47 CEST] <ubitux> it indeed looks related to lowres
[14:21:14 CEST] <ubitux> checksum matches without
[14:32:33 CEST] <Compn> rv20 probably never used for hd anyway
[14:32:36 CEST] <Compn> rv40 yes ;P
[14:33:10 CEST] <Daemon404> i dont think rv40 has loweres.
[14:34:27 CEST] <ubitux> michaelni: fate-rv20-1239 is failing for me on aarch64 since its addition in 1d64a9d9 (off-by-ones). the issue mismatch seems related to -lowres
[14:35:41 CEST] <wm4> this lowres crap is such a waste of time and energy
[14:35:41 CEST] <michaelni> ubitux, maybe something with bitexact MC and arm
[14:36:19 CEST] <ubitux> i tried adding sws bitexact/average_rnd just in case but didn't change anything
[14:36:28 CEST] <ubitux> any flag in mind i can try?
[14:38:04 CEST] <Daemon404> oh fyi: marton said he'd work on ffplay codecpar
[14:42:39 CEST] <michaelni> ubitux, dunno, but a bit shooting in the dark, is the difference also there with disabled asm ? and its only happening with lowres or the file without lowres differs too ?
[14:44:12 CEST] <michaelni> ubitux, also "aarch64 linux gcc 4.8 (Ubuntu/Linaro 4.8.2-13ubuntu1)" is passing on http://fatebeta.ffmpeg.org/
[14:44:29 CEST] <Daemon404> maybe it is compiler dependent?
[15:07:02 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:9897d9f4e074: examples/output: convert to codecpar
[15:07:03 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:d76972b58156: Merge commit '9897d9f4e074cdc6c7f2409885ddefe300f18dc7'
[15:08:00 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:a9e1f2cc61cb: examples/qsvdec: convert to codecpar
[15:08:01 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:030e69b4dcb9: Merge commit 'a9e1f2cc61cbd5606a087a60565e87923c39de5a'
[15:13:39 CEST] <Daemon404> that patch from nablet is just gross
[15:15:47 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:ac6d53589f36: examples/transcode_aac: convert to codecpar
[15:15:48 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:6bc5ef37cbf6: Merge commit 'ac6d53589f3631ae08467c784fb371a15c957f01'
[15:29:04 CEST] <Daemon404> do we have any tests that test src_movie?
[15:29:07 CEST] <Daemon404> ^ durandal_1707
[15:32:20 CEST] <Daemon404> TEST filter-testsrc2-yuv420p
[15:32:20 CEST] <Daemon404> TEST filter-testsrc2-yuv444p
[15:32:22 CEST] <Daemon404> ah
[15:32:31 CEST] <Daemon404> oh wait, no.
[15:34:49 CEST] <Daemon404> aside: er... is ffmpeg.org down?
[15:35:27 CEST] <kierank> yes
[15:35:45 CEST] <kierank> oh a bit slow
[15:36:01 CEST] <Daemon404> a bit? it wont load at all for me
[15:36:11 CEST] <Daemon404> oh finally. a few minutes later.
[15:36:14 CEST] <Daemon404> DoS?
[15:39:40 CEST] <durandal_1707> this ape decoder is not lossless here
[15:40:20 CEST] <durandal_1707> borked but numerous security additions
[15:40:31 CEST] <durandal_1707> *by
[15:42:48 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:1138eb5509d3: vsrc_movie: convert to codecpar
[15:42:49 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:8cae006c5646: Merge commit '1138eb5509d3db7f6d565cb45f137a786d22beb9'
[15:43:01 CEST] <Daemon404> durandal_1707, ported and tested src_movie
[15:44:04 CEST] <durandal_1707> people should not be allowed to code....
[15:46:43 CEST] <cone-985> ffmpeg 03Maxym Dmytrychenko 07master:a1335149fd61: qsvenc: store the sync point in heap memory
[15:46:44 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:acc155ac55ba: Merge commit 'a1335149fd610b16459d9281b611282cac51c950'
[15:56:34 CEST] <durandal_1707> so can I get someone to doublecheck ape decoder for me, by encoding with latest monkey encoder?
[15:57:03 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:3c53627ac17f: qsvdec: store the sync point in heap memory
[15:57:04 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:d30cf57a7b20: Merge commit '3c53627ac17fc6bdea5029be57da1e03b32d265d'
[15:58:54 CEST] <cone-985> ffmpeg 03Diego Biurrun 07master:d6e49096c0c3: idct: Only build prores IDCT if ProRes decoder is enabled
[15:58:55 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:8a6cc30b0428: Merge commit 'd6e49096c0c3c10ffb176761b0da150c93bedbf6'
[15:59:45 CEST] <durandal_1707> anyone?
[16:00:18 CEST] <cone-985> ffmpeg 03Vittorio Giovara 07master:fa55addd23c2: img2: Drop av_ prefix for a static function
[16:00:19 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:8a1c79024da4: Merge commit 'fa55addd23c2f168163175aee17adb125c2c0710'
[16:00:28 CEST] <Daemon404> durandal_1707, you cant use wine?
[16:01:16 CEST] <cone-985> ffmpeg 03Vittorio Giovara 07master:35b1cd343cd7: vc1dec: Drop commented out cruft
[16:01:17 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:e06f5c6f9483: Merge commit '35b1cd343cd703c1b0fc926dc43a92141a357380'
[16:02:00 CEST] <cone-985> ffmpeg 03Vittorio Giovara 07master:f91d94bdfc3f: vc1dec: Properly call deinit function on error
[16:02:01 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:015ca20030be: Merge commit 'f91d94bdfc3f5f83ff0be4d19d10d0a35697386f'
[16:02:30 CEST] <durandal_1707> I used, need confirmation
[16:03:24 CEST] <durandal_1707> By someone on windows
[16:03:40 CEST] <cone-985> ffmpeg 03Vittorio Giovara 07master:01f0e6a0c927: vc1dec: Fix leak on error for array allocations
[16:03:41 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:8cd1323103d3: Merge commit '01f0e6a0c9270f1d5bef08459a6f167cf55e0596'
[16:03:56 CEST] <Daemon404> durandal_1707, do you have a smaple for me to encode
[16:04:31 CEST] <durandal_1707> for the single sample tried it was off by one in bunch of samples
[16:05:16 CEST] <Daemon404> what do you need from me then
[16:05:21 CEST] <Daemon404> a .wav and matching .ape?
[16:05:21 CEST] <Compn> i'm on windows
[16:05:23 CEST] <Compn> whats up
[16:05:28 CEST] <Daemon404> oh hey Compn can do it
[16:05:29 CEST] Action: Daemon404 runs
[16:05:30 CEST] <durandal_1707> I'm in the city now, you could try any sample with silence parts
[16:05:43 CEST] <Compn> oh i'd need latest git ffmpeg...
[16:05:45 CEST] <Compn> cant compile here
[16:05:58 CEST] <durandal_1707> why?
[16:05:59 CEST] <Compn> Daemon404 could do me a crosscompile
[16:06:07 CEST] <Compn> mingw install always corrupts my hd
[16:06:23 CEST] Action: Compn afk brb
[16:06:35 CEST] <durandal_1707> looks like am alone in quest
[16:06:40 CEST] <cone-985> ffmpeg 03Vittorio Giovara 07master:e66fa35392cd: vc1dec: Check group allocations separatedly
[16:06:41 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:3dec7ed3cf04: Merge commit 'e66fa35392cd45d0a80774cd057fb765d60def43'
[16:07:07 CEST] <Daemon404> durandal_1707, i can provide a .ape and matching decoded .wav if you want
[16:07:23 CEST] <Daemon404> using the official encoder
[16:08:01 CEST] <durandal_1707> you just need to see if md5 is same
[16:09:05 CEST] <durandal_1707> I used latest monkey encoder with wine
[16:09:14 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:3e8fd93b6ab2: lavf: add a missing bump and APIchanges for the codecpar switch
[16:09:15 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:6586f62d1a7c: Merge commit '3e8fd93b6ab219221e17fa2b6243cc72cf2d69dc'
[16:09:26 CEST] <Daemon404> durandal_1707, i can do this in an hour or so
[16:09:53 CEST] <durandal_1707> That one couldn't properly decode 24 bit sample we have
[16:10:05 CEST] <durandal_1707> so its one big mess
[16:10:17 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:dc4983d78af2: APIchanges: add missing hashes and dates
[16:10:18 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:0dfbca73bbb3: Merge commit 'dc4983d78af2a666461654067d2e5d45b835358a'
[16:10:37 CEST] <durandal_1707> Daemon404: that would be fine
[16:10:58 CEST] <Daemon404> cool
[16:16:32 CEST] <ubitux> michaelni: -cpuflags none doesn't make a difference. if i remove -lowres from the fate test, regenerate the ref with the x86 code, and try again on aarch64, the test doesn't fail anymore
[16:16:48 CEST] <ubitux> michaelni: and yeah, i saw that on fate.f.o it doesn't fail for some reason
[16:19:43 CEST] <ubitux> i'm using gcc 4.9 though
[16:25:17 CEST] <ubitux> btw, mem leak in fate-yop
[16:27:38 CEST] <cone-985> ffmpeg 03Clément BSsch 07master:c921f4f68797: sws/aarch64: add ff_yuv2planeX_8_neon
[16:31:17 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:e7188a1a8481: avprobe: remove a pointless condition and a dead branch
[16:31:18 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:80195236c85d: Merge commit 'e7188a1a84817b8d4337340c21c552ad0b6cb2fd'
[16:33:20 CEST] <BtbN> i guess master is in an unstable state right now?
[16:33:29 CEST] <BtbN> running into this right now: https://bpaste.net/show/1ab5bcd5ab5c
[16:33:56 CEST] <nevcairiel> its not meant to be broken, feel free to send fixes
[16:34:51 CEST] <Daemon404> BtbN, concatdec is very "special" (stupid)
[16:34:54 CEST] <Daemon404> it may have been broke
[16:34:55 CEST] <Daemon404> n
[16:35:07 CEST] <BtbN> a concat list with more than two files, no matter what is in them, crashes
[16:35:25 CEST] <BtbN> (Still valid video files, not fuzzing)
[16:35:31 CEST] <Daemon404> what does safe 0 do
[16:35:46 CEST] <Daemon404> ah ... allows files with absolute paths
[16:35:49 CEST] <BtbN> disables the strange safe-file rule, so i can use a concat list with absolute paths
[16:35:57 CEST] <Daemon404> its not very strange
[16:36:38 CEST] <durandal_1707> have backtrace?
[16:37:14 CEST] <BtbN> gdb is still installing
[16:38:52 CEST] <BtbN> Is there anything better than the concat demuxer?
[16:40:02 CEST] <Daemon404> wq
[16:40:12 CEST] <wm4> x4->params.i_fps_num = avctx->time_base.den;
[16:40:12 CEST] <wm4> x4->params.i_fps_den = avctx->time_base.num * avctx->ticks_per_frame;
[16:40:21 CEST] <wm4> is this how encoders are supposed to get the framerate?
[16:40:47 CEST] <Daemon404> that sort of code has always been derpy
[16:41:27 CEST] <nevcairiel> there is a new framerate field in avctx which is supposed to do this, but previously it was that yes
[16:41:53 CEST] <wm4> well this is still in master
[16:42:55 CEST] <BtbN> not sure what to make of that backtrace, it looks like it failed to find the debug symbols? https://bpaste.net/show/771002fcc7c0
[16:44:16 CEST] <jkqxz> AVCodecContext.framerate: " * - encoding: unused". That one?
[16:44:35 CEST] <durandal_1707> using static or dynamic build?
[16:45:53 CEST] <nevcairiel> suppose its still time_base for encoders then
[16:48:43 CEST] <BtbN> seems like something is messed up with those input files as well, strange. They were created by passing an rtmp stream through the segment muxer
[16:50:44 CEST] <BtbN> durandal_1707, https://bpaste.net/show/979126636425
[16:52:04 CEST] <durandal_1707> that's ffprobe?
[16:52:19 CEST] <Daemon404> BtbN, i have a patch to test
[16:52:22 CEST] <Daemon404> for you
[16:52:23 CEST] <Daemon404> see if it fixes it
[16:52:46 CEST] <BtbN> durandal_1707, yes. But ffmpeg -i .. crashes the same
[16:53:43 CEST] <Daemon404> http://pastie.org/10793601
[16:53:47 CEST] <Daemon404> try this
[16:55:13 CEST] <nevcairiel> why would this start appearing now
[16:55:27 CEST] <Daemon404> nevcairiel, because concatdec used to just leak memory
[16:55:29 CEST] <Daemon404> i added frees
[16:55:42 CEST] <nevcairiel> how evil of you
[16:56:20 CEST] <BtbN> i also wonder what the hell the segment muxer did to these .ts segments. Something went horribly wrong there.
[16:56:40 CEST] <BtbN> Daemon404, src/libavformat/concatdec.c:369:21: error: used struct type value where scalar is required
[16:57:39 CEST] <Daemon404> running fate
[16:57:43 CEST] <Daemon404> im sure its just a silly thing
[16:57:47 CEST] <Daemon404> give a sec
[16:58:02 CEST] <nevcairiel> you check a struct in a boolean thing which is not a pointer
[16:58:22 CEST] <Daemon404> ah
[16:58:30 CEST] <Daemon404> just remove that if then i suppose
[16:58:52 CEST] <nevcairiel> should probably iterate over file->nb_streams, as that matches the actually allocated streams, instead of avf->nb_streams
[16:59:11 CEST] <Daemon404> ah that could be why yes
[16:59:18 CEST] <Daemon404> that should probably be the correct fix
[16:59:19 CEST] <nevcairiel> should be the same, except in an error case
[16:59:41 CEST] <Daemon404> BtbN, ignore the patch i pasted you and just change what nevcairiel said
[16:59:54 CEST] <Daemon404> checking if streams exists doesnt hurt though
[17:00:42 CEST] <BtbN> Heading home now, will test in an hour or so
[17:01:48 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:168a443d43b1: avprobe: print information from the codec descriptor
[17:01:49 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:6614214ece70: Merge commit '168a443d43b10ef6a3545d64b2f8bc90144ce4b7'
[17:02:37 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:c80344d01015: mpegvideo_enc: use avcodec_free_context() instead of av_free()
[17:02:38 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:95348174ef87: Merge commit 'c80344d0101558098a6cd2ed5082ff5fda7ca18b'
[17:14:54 CEST] <durandal_1707> Daemon404: don't forget
[17:19:33 CEST] <Daemon404> itll get done today... i have work still though
[17:33:28 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:c9478410c68c: avprobe: add local per-file state
[17:33:29 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:9d48aa6d7df6: Merge commit 'c9478410c68c04261f9cfcd80474607e50bd1852'
[17:46:53 CEST] <cone-985> ffmpeg 03Anton Khirnov 07master:567d6d5f9d14: avprobe: add local per-stream state
[17:46:54 CEST] <cone-985> ffmpeg 03Derek Buitenhuis 07master:48fb5294d03f: Merge commit '567d6d5f9d1400f00445183b3477391f58979aa3'
[18:07:38 CEST] <durandal_1707> is this ebu-stl subtitle xml thing?
[18:08:18 CEST] <kierank> no
[18:08:21 CEST] <kierank> that's ebu-tt
[18:08:27 CEST] <kierank> stl is the one from the 80s
[18:08:30 CEST] <michaelni> Daemon404, ive a small fix for examples/muxing, should i push it or wait? dont want to cause problems for any in progress mere
[18:08:40 CEST] <Daemon404> michaelni, theres no more merges for examples
[18:08:54 CEST] <Daemon404> it is safe to push
[18:10:10 CEST] <cone-985> ffmpeg 03Michael Niedermayer 07master:0c79c96cf20f: doc/examples/muxing: Add support to pass flags to muxer as since codecpar the codec flags are not available to the muxer anymore
[18:15:46 CEST] <cone-985> ffmpeg 03Matthieu Bouron 07master:4c2244127631: swscale/arm: add yuv2planeX_8_neon
[19:18:23 CEST] <BtbN> nevcairiel, Daemon404, durandal_1707: That fixed the crash
[19:18:40 CEST] <BtbN> https://gist.github.com/3c5f8c5cb437530706b6c40cb050bd17
[19:19:47 CEST] <BtbN> Should I just push that, or send it to the ML?
[19:30:35 CEST] <durandal_1707> Imho just push, isn't that file under direct maintership?
[19:31:07 CEST] <BtbN> grep for concat in MAINTAINERS yields no results
[19:34:18 CEST] <durandal_1707> then just push IMO
[20:09:34 CEST] <wm4> #define DEFAULT 0 //should be NAN but it does not work as it is not a constant in glibc as required by ANSI/ISO C
[20:09:37 CEST] <wm4> loving this
[20:11:35 CEST] <TD-Linux> how old is that line
[20:14:28 CEST] <wm4> 2005
[20:15:12 CEST] <wm4> "AVOption first try"
[20:29:54 CEST] <cone-985> ffmpeg 03Lou Logan 07master:03d8fee912a4: doc/filters: document testsrc2 source filter
[22:25:50 CEST] <cone-985> ffmpeg 03Timo Rothenpieler 07master:901b0f1a219e: avformat/concatdec: Use correct stream count on close
[22:39:10 CEST] <durandal_170> Daemon404: looks like I found bug and not regression
[22:40:16 CEST] <Daemon404> ok... cause i didnr get to testing :x
[22:47:29 CEST] <omerjerk> hey what's the best way to allocate a 2d array in ffmpeg ?
[22:48:15 CEST] <omerjerk> for e.g. float** array = av_malloc_array(5, sizeof(float*));
[22:48:59 CEST] <omerjerk> and then iterate over array[i], and do array[i] = av_malloc_array(5, sizeof(float));
[22:49:13 CEST] <omerjerk> is this okay ?
[22:50:21 CEST] <BtbN> why not just allocate a normal array and calculate the position?
[22:50:24 CEST] <ubitux> if it's small you can also do a 1d alloc and access y*N+x
[22:51:12 CEST] <omerjerk> I can do that. But just wondering what should I go with.
[22:51:45 CEST] <ubitux> if fixed, you can add a[5][5] into the local context, it will be heap allocated automatically
[22:51:51 CEST] <omerjerk> the array's dimensions will be number of channels * frame size
[22:52:11 CEST] <omerjerk> it's not fixed.
[22:52:34 CEST] <ubitux> then your initial solution makes sense to me
[22:52:55 CEST] <nevcairiel> sounds like you want storage for your audio samples, you probably want get_buffer that
[22:53:36 CEST] <omerjerk> yes. I want to store the samples in a 2d array inside the context.
[22:53:43 CEST] <nevcairiel> what for
[22:53:57 CEST] <omerjerk> to write to the file later.
[23:18:03 CEST] <rcombs> wat
[23:18:20 CEST] <rcombs> omerjerk: you seem to be describing an AVFrame
[23:24:53 CEST] <omerjerk> rcombs: I'm adding a 2d raw_float array here - https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L228
[23:27:35 CEST] <nevcairiel> there appears to already be one for int32 samples, so why don't you do exactly what it does
[00:00:00 CEST] --- Tue Apr 12 2016
1
0
[00:30:48 CEST] <satt> hey all, got a quick question here
[00:32:10 CEST] <satt> I need to make a thumbnail for a video file contained within a zip, ideally without unzipping the file to temp storage first - is this possible?
[00:32:40 CEST] <satt> it'll be running on thousands of short (under 2mb) files on AWS, so the less cpu/file storage requirements the better, otherwise it'll get too expensive
[00:34:50 CEST] <JEEB> for API you could make your own AVIO wrapper that handles the decompression in memory and the actual file size getting etc
[00:35:17 CEST] <JEEB> for ffmpeg cli I'm not sure, for some stuff you could just do piping from an extraction process
[00:35:31 CEST] <JEEB> but if you need seeking... that might take a while until you get to the end
[00:36:37 CEST] <satt> it could be just the first frame of the video file, so no seeking necessary
[00:37:26 CEST] <satt> I'm not sure what you mean by API there though - is there some ffmpeg api I can use? I was planning on using the ffmpeg cli with python or node.js on AWS lambda
[00:39:34 CEST] <JEEB> ffmpeg.c uses libavformat/-codec etc :P
[00:39:49 CEST] <JEEB> those are the libraries that most things basing on FFmpeg's libraries use
[00:40:24 CEST] <satt> ah ok found the documentation here: https://ffmpeg.org/doxygen/trunk/index.html
[00:41:01 CEST] <JEEB> also not all containers can be decoded A-to-B
[00:41:14 CEST] <JEEB> if you know your stuff is such you can do that, fine
[00:42:20 CEST] <satt> I'll have to investigate the source files, they're coming from snapchat's api, where the original videos are shot on a bunch of different devices
[00:42:21 CEST] <JEEB> for example with ISOBMFF (what is colloquially called "mp4") unless you do a second pass during writing the "index" with the data required to initialize decoders is put in the end due to the rest of the file having to be written for that data to have been gotten
[00:42:56 CEST] <satt> ah damn. I know almost all my files are in an mp4 container
[00:43:43 CEST] <JEEB> ISOBMFF = ISO Base Media File Format
[00:44:45 CEST] <satt> so that would mean I'd need to extract the whole file in order to pull a frame and make a thumbnail from it
[00:46:01 CEST] <satt> thanks for the advice, I'll do a little more research and see what I can come up with
[00:46:02 CEST] <JEEB> depends, either you just have to read through the whole thing before you get output or you make your own AVIO wrapper that handles decompression of the requested parts from the compressed file
[00:47:37 CEST] <satt> right ok - I'll definitely do some research into making an AVIO wrapper then. thanks again JEEB
[03:52:07 CEST] <Fusl> is there a way to dynamically normalize the volume of an audio stream containing parts that are very loud and some that are very silent?
[03:54:10 CEST] <c_14> Have you looked at dynaudnorm, or maybe acompressor or alimiter
[03:54:12 CEST] <c_14> ?
[08:25:08 CEST] <jml2> hi
[10:34:49 CEST] <termos> I'm getting some "Buffer queue overflow, dropping." messages and after this my audio and video is out of sync, is there something I need to do to keep this from happening?
[11:55:13 CEST] <lost_RD> hello all
[13:31:26 CEST] <TheGreatDoc> Hello
[13:31:43 CEST] <TheGreatDoc> May I have a little bit help for ffmpeg to udp multicast?
[13:33:44 CEST] <TheGreatDoc> Im trying to stream to udp multicast, but I cant see it with VLC
[13:34:18 CEST] <TheGreatDoc> When I press play in the vlc, it does nothing
[13:35:03 CEST] <TheGreatDoc> But i can see the multicast packets with wireshark/tcpdump
[13:35:36 CEST] <TheGreatDoc> Streaming to rtmp or writting to file works perfect
[13:36:00 CEST] <TheGreatDoc> but doing a -f mpegts udp://224.0.0.251:5001 doesnt works
[13:43:26 CEST] <BtbN> that will probably just blindly fire UDP packets at that address. No idea if Multicast works that easily. You probably want to use something like RDP.
[13:46:01 CEST] <TheGreatDoc> I really need multicast udp or rtp
[14:31:31 CEST] <t4nk633> hello guys
[14:32:15 CEST] <t4nk633> how can i optupt ffmpeg devices to file
[14:32:16 CEST] <t4nk633> ffmpeg -list_devices true -f dshow -i dummy >devices.txt
[14:33:03 CEST] <DHE> BtbN: while that does work for multicast just by setting a target address in the multicast range under linux, there are issues with how ffmpeg does it. you could run into packet loss if there are speed variations in the path from sender to recipient or network congestion
[14:41:17 CEST] <TheGreatDoc> DHE, but ffmpeg are doing (or me) something wrong in the multicast stream
[14:41:23 CEST] <TheGreatDoc> i cant see it in vlc, even in localhost
[14:45:46 CEST] <DHE> TheGreatDoc: is it processing real time?
[14:46:19 CEST] <TheGreatDoc> yes
[14:46:37 CEST] <DHE> I mostly deal with over-the-air content where ffmpeg is ultimately limited by the speed of data coming from the transmitter which is, of course, realtime
[14:46:39 CEST] <TheGreatDoc> ./bmdcapture -m 1 -A 2 -V 4 -F nut -f pipe:1 | ../ffmpeg-3.0.1/ffmpeg -re -i - -c:v libx264 -pix_fmt yuv420p -profile:v main -level 4.1 -vb 8000k -c:a libmp3lame -ab 256k -ar:a 44100 -f mpegts udp://224.0.0.251:5001
[14:47:20 CEST] <TheGreatDoc> the thing is. If I stream flv to rtmp works. mpegts multicast seems not
[14:47:32 CEST] <DHE> and while this is running can you run (on the same system) ffprobe udp://224.0.0.251:5001 ?
[14:47:40 CEST] <TheGreatDoc> sure
[14:47:48 CEST] <DHE> successfully?
[14:47:56 CEST] <TheGreatDoc> some of those
[14:47:57 CEST] <TheGreatDoc> Last message repeated 1 times
[14:47:57 CEST] <TheGreatDoc> [h264 @ 0x21e6500] decode_slice_header error
[14:47:57 CEST] <TheGreatDoc> [h264 @ 0x21e6500] no frame!
[14:47:59 CEST] <TheGreatDoc> and then
[14:48:06 CEST] <TheGreatDoc> Input #0, mpegts, from 'udp://224.0.0.251:5001':
[14:48:06 CEST] <TheGreatDoc> Duration: N/A, start: 8.821478, bitrate: N/A
[14:48:06 CEST] <TheGreatDoc> Program 1
[14:48:06 CEST] <TheGreatDoc> Metadata:
[14:48:06 CEST] <TheGreatDoc> service_name : Service01
[14:48:06 CEST] <TheGreatDoc> service_provider: FFmpeg
[14:48:06 CEST] <TheGreatDoc> Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 720x576, 25 fps, 25 tbr, 90k tbn, 50 tbc
[14:48:07 CEST] <TheGreatDoc> Stream #0:1[0x101]: Audio: mp3 ([3][0][0][0] / 0x0003), 44100 Hz, stereo, s16p, 256 kb/s
[14:48:09 CEST] <DHE> yeah that'll happen. you're joining mid-stream so you don't start on a keyframe
[14:48:11 CEST] <DHE> oh goddammit
[14:49:00 CEST] <TheGreatDoc> so its seems its ok, but cant view on vlc
[14:49:18 CEST] <DHE> can ffprobe on a remote system view it?
[14:50:00 CEST] <TheGreatDoc> mmmm, dont have ffprobe on other system. The only other computer is windows but I may do some things to have another linux with ffprobe on it
[14:50:08 CEST] <TheGreatDoc> but it will take a while :)
[14:55:04 CEST] <DHE> there's windows versions of ffmpeg... doesn't need to be linux
[14:55:17 CEST] <DHE> but yeah, linux is my specialty
[14:59:09 CEST] <t4nk633> how can i do this ffmpeg -list_devices true -f dshow -i dummy >devices.txt
[14:59:36 CEST] <t4nk633> list of devices to file please any help i get it on comand prompt under windows7 i need to have listed in a file
[15:18:21 CEST] <andross> hey
[15:18:49 CEST] <andross> JEEB you free?
[15:21:52 CEST] <neha_> So I am using ffmpeg for screen capture
[15:21:59 CEST] <neha_> and the command I am using is
[15:22:09 CEST] <neha_> ffmpeg -y -framerate 8 -f avfoundation -i 0:0 -i /usr/local/.browserstack/watermark.png -filter_complex "overlay=main_w-overlay_w-15:main_h-overlay_h-15" -strict experimental -vcodec libx264 -profile:v baseline -preset ultrafast -crf 24 -r 8 -pix_fmt yuv420p -ab 16k
[15:22:31 CEST] <neha_> ffmpeg -y -framerate 8 -f avfoundation -i 0:0 -i watermark.png -filter_complex "overlay=main_w-overlay_w-15:main_h-overlay_h-15" -strict experimental -vcodec libx264 -profile:v baseline -preset ultrafast -crf 24 -r 8 -pix_fmt yuv420p -ab 16k
[15:22:35 CEST] <neha_> this one ^^
[15:22:45 CEST] <neha_> and I'm continourly getting an error
[15:22:54 CEST] <neha_> on the command line
[15:23:00 CEST] <neha_> though my o/p is perfect
[15:23:09 CEST] <neha_> but the terminal output is too large
[15:23:52 CEST] <neha_> Apr 11 08:26:26 mac-208-78-105-62 ffmpeg[3880]: [08:26:26.341] CMSampleBufferGetImageBuffer signalled err=-12731 (kCMSampleBufferError_RequiredParameterMissing) (!sbuf) at /Library/Caches/com.apple.xbs/Sources/CoreMedia_frameworks/CoreMedia-1731.15.4/Sources/Core/FigSampleBuffer/FigSampleBuffer.c line 2394 0 CoreMedia 0x00007fff8ad4a7af CMSampleBufferGetImageBuffer + 138 1 ffmpeg
[15:24:38 CEST] <neha_> http://pastebin.com/avVTKcSH
[15:24:53 CEST] <neha_> pasted it on pastebin for better visibility
[15:25:01 CEST] <neha_> this only happens in mac elc
[15:25:06 CEST] <neha_> is there a way I can disable this
[15:25:09 CEST] <neha_> ?
[15:30:17 CEST] <andross> furq: ?
[15:38:04 CEST] <fritsch> neha_: nice null ptr
[15:39:48 CEST] <neha__> fritsch then how should I make it run?
[15:39:54 CEST] <neha__> I mean I undertood the Null poritner
[15:40:02 CEST] <neha__> but is there something in my command arguments?
[15:40:11 CEST] <neha__> because is getting the error
[15:40:15 CEST] <neha__> @fritsch
[15:41:34 CEST] <fritsch> no idea, sorry
[15:41:45 CEST] <fritsch> make sure to use latest and greatest ffmpeg
[15:41:51 CEST] <fritsch> and if error persists -> bugreport
[15:42:19 CEST] <neha__> ok!
[15:42:26 CEST] <neha__> cool thanks :)
[15:42:36 CEST] <fritsch> make sure to provide the full output of this ffmpeg command
[15:42:41 CEST] <fritsch> gone
[15:43:31 CEST] <neha__> is there a way I can make the output less noisy? @fritsch
[15:43:52 CEST] <fritsch> the more noise the better
[15:43:53 CEST] <neha__> the output is too much and now I'm trying to hide the output
[15:44:02 CEST] <neha__> not just emit to dev/null but soemthing else?
[15:44:09 CEST] <neha__> so that ffmpeg doesnt report it
[15:44:11 CEST] <neha__> or something
[15:44:21 CEST] <fritsch> 2>&1 > /dev/null
[15:45:18 CEST] <neha__> yeah but this is taking away the entire stderr
[15:45:31 CEST] <neha__> I only want to remove this and the other useless stuff :(
[15:54:40 CEST] <andross> can anyone let me know if there are known issues when compiling with lame on ubuntu that i need to watch out for?
[16:14:33 CEST] <TheGreatDoc> DHE you still up?
[16:15:22 CEST] <TheGreatDoc> Im trying with windows ffprobe/ffplay with no luck. Both do nothing
[16:16:35 CEST] <TheGreatDoc> anyways, im unable to view the stream with vlc in localhost too
[16:22:38 CEST] <BurnerGR> I'm trying to transport a stream from ffmpeg (dshow input) 1080p@60fps to ffmpeg on another box via gigabit lan, in a lossless or low loss quality, which codecs/format/protocol is best suited for this purpose?
[16:23:51 CEST] <DHE> ffv1 is the ffmpeg lossless codec, but the bitrate is pretty high crazy. H264 has lossless mode if you set "-qp 0" but there is 422 colourspace reduction by default
[16:24:20 CEST] <DHE> TheGreatDoc: on the same local LAN?
[16:24:34 CEST] <BurnerGR> yes, local lan, high quality
[16:24:52 CEST] <DHE> on the linux system you should be able to tcpdump the NIC facing the LAN with filter "udp port 5001" and see the video stream
[16:25:29 CEST] <BurnerGR> humm, i didnt think of that, you mean the raw bitstream from dshow?
[16:25:42 CEST] <DHE> BurnerGR: I'm talking to two people here
[16:25:45 CEST] <BurnerGR> isnt that way higher than 1gbit?
[16:25:52 CEST] <BurnerGR> aaah ok, sorry
[16:26:03 CEST] <DHE> yes, 60fps 1080p will blow gigabit out of the water
[16:26:04 CEST] <ethe> BurnerGR why would it be higher than 1gbit?
[16:26:17 CEST] <DHE> ethe: in raw RGB or YUV, yes it will
[16:26:30 CEST] <ethe> oh, raw. yeah
[16:26:45 CEST] <DHE> hence the use of ffv1 or x264
[16:29:32 CEST] <BurnerGR> i tested with x264, mpegts via udp unicast, i got a horrible studdering, but no warnings or errors on ffmpeg output, the bandwidth were about 450mbit
[16:31:04 CEST] <TheGreatDoc> DHE yes, of course
[16:31:22 CEST] <TheGreatDoc> Same LAN and same computer
[16:31:43 CEST] <TheGreatDoc> in the computer im doing ffmpeg to udp multicast, cant view in vlc the multicast stream
[16:32:10 CEST] <TheGreatDoc> im compiling ffmpeg with decklink support, as the decklink sdi is the input source
[16:32:29 CEST] <TheGreatDoc> only to skip the bmdcapture step
[16:32:38 CEST] <TheGreatDoc> but dont think it will fix the issue :(
[16:34:18 CEST] <andross> i timed out, if anyone replied to my previous message?
[16:34:53 CEST] <TheGreatDoc> nobody replied but I can tell you that im compiling in debian without any issue
[16:35:04 CEST] <TheGreatDoc> did you do install the lame codecs?
[16:35:56 CEST] <andross> i havent tried to compile yet, but it was mentioned to me previously i should do a pure vanilla compile first before trying to compile with lame
[16:36:12 CEST] <andross> which i have done
[16:36:25 CEST] <andross> i dont know if theres some special additional steps i need to do before compiling with lame
[16:37:43 CEST] <BurnerGR> TheGreatDoc, I'm doing something very similar to what you are doing, and i have loads of problems as soon as i get anything over ~5mbit over udp :|
[16:38:17 CEST] <TheGreatDoc> but the rate is arround 4mbit
[16:38:34 CEST] <TheGreatDoc> has 8000vb but only using 4000 or so
[16:38:45 CEST] <TheGreatDoc> BurnerGR, did you at least play it on vlc?
[16:38:57 CEST] <TheGreatDoc> my vlc just dont recognize the stream
[16:39:00 CEST] <TheGreatDoc> plays and stops
[16:40:12 CEST] <BurnerGR> TheGreatDoc, yes, it plays on vlc and ffplay, with lower bandwidth
[16:40:23 CEST] <TheGreatDoc> im trying right now
[16:42:49 CEST] <BurnerGR> TheGreatDoc, try setting a gop value
[16:46:26 CEST] <andross> my vbox keeps crashing....
[16:46:29 CEST] <TheGreatDoc> I've capturing directly from decklink and no luck
[16:46:43 CEST] <TheGreatDoc> BurnerGR, i set the br to 4000 and still the same
[16:46:51 CEST] <Mavrik> G'day.
[16:46:58 CEST] <Mavrik> TheGreatDoc, what's your issue?
[16:47:11 CEST] <Mavrik> With decklink?
[16:47:16 CEST] <TheGreatDoc> I cant multicast stream
[16:47:25 CEST] <TheGreatDoc> no, the decklink works perfect, is the multicast udp stream
[16:47:44 CEST] <TheGreatDoc> And this is driving me crazy :D
[16:48:05 CEST] <TheGreatDoc> G'day to you too
[16:48:28 CEST] <Mavrik> Ah :)
[16:48:53 CEST] <TheGreatDoc> Can you, by any chance, help me on that?
[16:48:57 CEST] <TheGreatDoc> :):):)
[16:49:37 CEST] <Mavrik> I guess :P
[16:49:49 CEST] <TheGreatDoc> Im doing this:
[16:49:53 CEST] <Mavrik> Didn't have much trouble with it tbh
[16:50:05 CEST] <TheGreatDoc> ./ffmpeg -re -f decklink -i "DeckLink SDI 4K@2" -c:v libx264 -pix_fmt yuv420p -profile:v main -level 4.1 -vb 4000k -c:a libmp3lame -ab 256k -ar:a 44100 -f mpegts udp://224.0.0.251:5001
[16:50:26 CEST] <TheGreatDoc> I cant see the stream even in the same computer with vlc
[16:50:31 CEST] <TheGreatDoc> ffprobe says is ok
[16:50:46 CEST] <TheGreatDoc> ffprobe on another computer (windows, same lan, do nothing)
[16:50:46 CEST] <Mavrik> hmm
[16:50:56 CEST] <Mavrik> ok, first, did you try unicast?
[16:51:05 CEST] <TheGreatDoc> I try rtmp and works
[16:51:09 CEST] <TheGreatDoc> tried*
[16:51:10 CEST] <Mavrik> Just to see if it's ffmpeg or network that's the issue.
[16:51:19 CEST] <Mavrik> Try udp://<IP of another machine>:<port>
[16:51:26 CEST] <TheGreatDoc> Oh, that I tried too
[16:51:28 CEST] <Mavrik> and open udp://127.0.0.1:<port> on the other machine
[16:51:37 CEST] <TheGreatDoc> no work
[16:51:52 CEST] <Mavrik> Well, I'd pull out wireshark at that point :/
[16:52:10 CEST] <Mavrik> See what's sent on host machine and what's received on target machine
[16:52:15 CEST] <TheGreatDoc> oh, thats the funny, in wireshark (in multicast at least) the packets are there
[16:52:21 CEST] <TheGreatDoc> let me do you test in a minute
[16:52:38 CEST] <hc2p> hey, i can't set the playlist-type to EVENT when encoding to HLS. Says "...Unrecognized option 'hls_playlist_type'". ffmpeg version 3.0.1, libavformat 57.25.100
[16:52:47 CEST] <TheGreatDoc> F**K
[16:52:58 CEST] <Mavrik> TheGreatDoc, also remember that VLC is retarded and you need to set source as "udp://@<ip>:port"
[16:53:05 CEST] <TheGreatDoc> im opening the multicast address on the other computer
[16:53:12 CEST] <TheGreatDoc> and now is playing with unicast ffmpeg
[16:53:24 CEST] <Mavrik> hmm
[16:53:30 CEST] <TheGreatDoc> I mean, in the vlc Im opening udp://@224.0.0.251:5001
[16:53:35 CEST] <Mavrik> That sounds like the player isn't joining the multicast group
[16:53:41 CEST] <Mavrik> Or the router is drunk.
[16:53:50 CEST] <TheGreatDoc> and with ffmpeg im streaming to udp://192.168.250.2:5001
[16:54:12 CEST] <TheGreatDoc> no no, with multicast address on ffmpeg, I recieve the packets in the VLC computer, but cant open the stream
[16:54:46 CEST] <TheGreatDoc> thats a little bit crazy, I know
[16:57:51 CEST] <TheGreatDoc> But Im pretty sure I need to do the multicast
[16:59:54 CEST] <Mavrik> hmm.
[17:00:15 CEST] <Mavrik> If you see the packets on the client machine, then there's something wrong with the player
[17:00:28 CEST] <Mavrik> Perhaps multiple network cards and the players are binding to the wrong ones?
[17:00:30 CEST] <Mavrik> Broken routes?
[17:01:17 CEST] <TheGreatDoc> Mavrik, I cant view the stream even in the same machine is doing the stream
[17:01:41 CEST] <Mavrik> That can still happen when network routes are broken :)
[17:01:51 CEST] <Mavrik> But I'm not a networking expert tho :/
[17:03:57 CEST] <TheGreatDoc> Im doing some tests :)
[17:05:27 CEST] <hc2p> the option "hls_playlist_type" is mentioned in the formats docs for the HLS muxer. I get an error using it: "...Unrecognized option 'hls_playlist_type'". ffmpeg version 3.0.1, libavformat 57.25.100
[17:05:43 CEST] <hc2p> any help highly appreciated
[17:16:27 CEST] <andross> well
[17:16:33 CEST] <andross> when trying to configure with lame i get this error:
[17:16:38 CEST] <andross> ERROR: libmp3lame >= 3.98.3 not found
[17:17:13 CEST] <andross> ive installed libmp3lame-dev
[17:17:49 CEST] <furq> if you're cross-compiling ffmpeg you need to cross-compile any libs you want to use
[17:18:20 CEST] <andross> ah, so how do i cross compile libmp3lame
[17:20:25 CEST] <TheGreatDoc> Mavrik, I've setup tsreader to check the stream
[17:20:44 CEST] <TheGreatDoc> tsreader start reading the stream and fail after 1 to 2 secs
[17:20:59 CEST] <TheGreatDoc> and then stop reading
[17:21:12 CEST] <TheGreatDoc> I've tested tsreader with other multicast stream and never stops reading
[17:21:23 CEST] <TheGreatDoc> So it must be some issue on source (ffmpeg)
[17:29:47 CEST] <TheGreatDoc> ./ffmpeg -re -f decklink -i "DeckLink SDI 4K@2" -c:v mpeg2video -pix_fmt yuv420p -r 25 -g 15 -b 3500k -bt 300k -acodec mp2 -ac 2 -ab 192k -ar 44100 -async 1 -f mpegts udp://224.0.0.251:5001
[17:29:54 CEST] <andross> whoever said cross compiling ffmpeg on linux was easy must have been smoking something...
[17:29:58 CEST] <andross> literally no clue what im doing
[17:30:01 CEST] <TheGreatDoc> im doing this now, but no luck
[17:30:23 CEST] <andross> built libmp3lame cross compiled, ffmpeg make still cant find it
[17:30:36 CEST] <TheGreatDoc> BurnerGR
[17:31:12 CEST] <TheGreatDoc> andross, in debian i just compiled libmp3lame, make make install and go
[17:31:25 CEST] <furq> andross: where did you install it
[17:31:34 CEST] <furq> and have you set your PKG_CONFIG_PATH to point to the installed .pc
[17:31:46 CEST] <furq> otherwise it'll still be pointing to the native .pc
[17:32:05 CEST] <andross> i dont know about any of this stuff since im not a linux user
[17:32:28 CEST] <andross> libmp3lame installed to wherver make install installs it
[17:32:42 CEST] <andross> i dont know what a .pc is
[17:33:05 CEST] <TheGreatDoc> so you configure, make and make install libmp3lame
[17:33:14 CEST] <andross> ive done that
[17:33:27 CEST] <TheGreatDoc> and then , in the configure of ffmpeg you set --enable-libmp3lame
[17:33:32 CEST] <andross> done that
[17:33:39 CEST] <TheGreatDoc> and whats the error?
[17:33:49 CEST] <andross> ERROR: libmp3lame >= 3.98.3 not found
[17:34:12 CEST] <TheGreatDoc> and what libmp3lame are you installing?
[17:34:34 CEST] <TheGreatDoc> what version I mean :)
[17:34:43 CEST] <andross> http://downloads.sourceforge.net/project/lame/lame/3.99/lame-3.99.5.tar.gz
[17:34:50 CEST] <furq> well it's not 3.98.3 because that came out in 2010
[17:35:54 CEST] <TheGreatDoc> Im using just that one
[17:35:56 CEST] <TheGreatDoc> 3.99.5
[17:36:03 CEST] <andross> i extracted it to a sub folder within ffmpeg
[17:36:25 CEST] <furq> ignore the stuff i said about pkg-config, apparently lame doesn't create a pkg-config file
[17:37:36 CEST] <TheGreatDoc> I've downloaded to my home, configure make and make install. Just only that, and works perfectly (in debian)
[17:37:48 CEST] <andross> im in ubuntu
[17:38:00 CEST] <TheGreatDoc> I know, but should not be much difference i guess
[17:38:03 CEST] <andross> i had to sudo make install as i got permission errors on just make install
[17:38:15 CEST] <TheGreatDoc> yeah, im running all on root
[17:38:30 CEST] <TheGreatDoc> so everything should be the same
[17:38:34 CEST] <andross> im not saying libmp3 didnt build anyway
[17:38:40 CEST] <andross> im talking about on buildng ffmpeg
[17:38:45 CEST] <andross> it doesnt find libmp3lame still
[17:38:51 CEST] <TheGreatDoc> did you tried doing "sudo su"
[17:39:01 CEST] <TheGreatDoc> and the configure, make on ffmpeg?
[17:39:36 CEST] <furq> no
[17:39:49 CEST] <furq> if you ever have to run configure as root then you've fucked something up
[17:40:32 CEST] <andross> ./configure --cross-prefix=i686-w64-mingw32- --arch=i686 --target-os=mingw32 --disable-static --enable-shared --pkg-config='pkg-config --static' --extra-ldflags=-static-libgcc --enable-libmp3lame
[17:40:36 CEST] <andross> this is my command
[17:41:30 CEST] <furq> andross: recompile lame with --prefix=/my/install/path
[17:41:55 CEST] <furq> then configure ffmpeg with LDFLAGS=-L/my/install/path/lib ./configure
[17:42:12 CEST] <furq> you might also need CFLAGS=-I/my/install/path/include
[17:42:29 CEST] <andross> how do i delete the previous lame install
[17:44:00 CEST] <furq> try make uninstall
[17:44:03 CEST] <furq> before rerunning configure
[17:45:02 CEST] <furq> /my/install/path should probably be somewhere in your home dir or somewhere else you have write access to
[17:45:30 CEST] <andross> say i want to just install to a folder called libmp3lame on my home
[17:45:40 CEST] <andross> what is the path, ~/libmp3lame/ ?
[17:45:49 CEST] <furq> yeah
[17:45:59 CEST] <furq> or $HOME/libmp3lame or /home/andross/libmp3lame
[17:46:04 CEST] <andross> right got it
[17:46:18 CEST] <furq> i would recommend using ~/build as your prefix in case you want to install more libraries
[17:46:30 CEST] <furq> granted you could just have fdk-aac built in ~/libmp3lame but that's confusing
[17:48:00 CEST] <furq> also when compiling lame, if you didn't set it before, you'll need --host=i686_w64_mingw32
[17:48:33 CEST] <furq> or whichever cross compiler you're using for ffmpeg
[17:50:12 CEST] <andross> so /home/andross/build/libmp3lame ?
[17:50:33 CEST] <furq> no, don't make a subdirectory
[17:50:49 CEST] <andross> /home/andross/build
[17:50:56 CEST] <furq> all your cross-compiled headers and libs will go in ~/build/include, ~/build/lib etc
[17:56:19 CEST] <andross> how do i stop terminal immedately processing my command on copy & paste?
[17:57:09 CEST] <furq> depends on the terminal
[17:57:19 CEST] <furq> it's easier to just cancel the command and then hit up
[17:57:54 CEST] <andross> Unknown option "LDFLAGS=-L/home/andross/build/lib".
[17:57:54 CEST] <andross> See ./configure --help for available options.
[17:59:00 CEST] <salviaD> tried to install ffmpeg and got this msg "ffmpeg breaks libav-tools" what the ..... ?
[17:59:14 CEST] <furq> andross: http://sprunge.us/ESLS
[17:59:23 CEST] <furq> that should work if you're using bash, and you almost certainly are
[17:59:44 CEST] <furq> salviaD: which old version of ubuntu is that
[17:59:46 CEST] <andross> i already did make clean so i think make uninstall doesnt work now
[17:59:57 CEST] <andross> oops, was page up'd
[18:00:10 CEST] <furq> it doesn't really matter anyway
[18:00:12 CEST] <salviaD> furq: raspberry deban jessie
[18:00:23 CEST] <furq> it sounds like you just installed it native
[18:00:34 CEST] <andross> thanks furq
[18:00:51 CEST] <furq> salviaD: raspbian or proper debian
[18:01:33 CEST] <salviaD> raspbian
[18:01:56 CEST] <andross> ok, making...
[18:01:57 CEST] <furq> where are you installing ffmpeg from
[18:03:29 CEST] <andross> ~/ffmpeg/
[18:03:34 CEST] <salviaD> furq: wget http://ftp.us.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_2.8.6-1+b2_armhf.… and dpkg -i
[18:03:50 CEST] <andross> nvm
[18:03:59 CEST] <furq> if that's an rpi 1 then that package won't work anyway
[18:06:08 CEST] <salviaD> furq: Is there ny repo I can add to be able to apt-get install ffmpeg ?
[18:06:25 CEST] <furq> not that i know of, i've only ever used an rpi2
[18:06:41 CEST] <furq> debian armhf packages are compiled for armv7, so they won't work on an rpi1
[18:06:44 CEST] <furq> hence the need for raspbian
[18:12:33 CEST] <TheGreatDoc> anyone with ffmpeg to udp multicast experience?
[18:23:47 CEST] <anagh> hi there
[18:24:53 CEST] <anagh> when i tired ot install opencv in ubuntu 15.1 i m getting this error
[18:25:08 CEST] <anagh> libxvid not found
[18:28:11 CEST] <TheGreatDoc> anyone with ffmpeg to udp multicast experience?
[18:46:00 CEST] Last message repeated 1 time(s).
[18:46:36 CEST] <DHE> well, yes. but I made some hacks to the process
[18:49:21 CEST] <TheGreatDoc> DHE, hi again
[18:49:31 CEST] <TheGreatDoc> I still stucked >D
[18:49:35 CEST] <TheGreatDoc> :D
[18:50:05 CEST] <TheGreatDoc> Last I tried is with tsreader to see the stream
[18:50:23 CEST] <TheGreatDoc> tsreader start reading but stops recieving after 1 to 2 seconds
[18:50:38 CEST] <TheGreatDoc> I-ve tested tsreader with other multicast stream and works perfect
[18:52:04 CEST] <TheGreatDoc> If i do udp unicast it works, but multicast doesnt
[18:57:05 CEST] <DHE> is the sender host multi-homed? dual NICs?
[18:58:13 CEST] <johnnny22-afk> When doing -c copy , the source has no q=values, while the output for the content seems to have q=2-31 .. does this mean that something gets changed ?
[18:58:42 CEST] <johnnny22-afk> that is for the video part.
[18:59:02 CEST] <johnnny22-afk> Also, for the audio part, the audio input says: fltp , while the output doesn't specify that.
[18:59:49 CEST] <DHE> q=values are encoder parameters. if no encoders are working, there's no values to print
[19:00:54 CEST] <johnnny22-afk> but I put -c copy, shouldn't it print nothing then for that output video ?
[19:01:12 CEST] <TheGreatDoc> No, sender is not multihomed
[19:01:20 CEST] <TheGreatDoc> only one nic
[19:02:01 CEST] <TheGreatDoc> tsreader, in other computer, start recieving and reading the stream but stop after 1 or 2 seconds
[19:02:20 CEST] <TheGreatDoc> also, wireshark sais the packets are there
[19:14:30 CEST] <pfelt> afternoon all! i've got an ffmpeg command i'm running that pulls two streams and hstacks them. i'm playing with a ton of different ways to no avail. is there any way for me to be able to kill one of the streams and restart it without having to restart the other? (i've tried 3 total ffmpeg commands and pipes and that doesn't seem to do it)
[19:19:52 CEST] <durandal_1707> pfelt: you want to loop it?
[19:24:34 CEST] <pfelt> durandal_1707: negative, it's a network feed. i'd either like to just restart it with the same url (it'll have different content) or change it to a new url
[19:27:39 CEST] <durandal_1707> pfelt: after exact time?
[19:30:34 CEST] <pfelt> durandal_1707: sry. not sure i follow the question
[19:31:28 CEST] <durandal_1707> Duration of one stream is variable?
[19:32:29 CEST] <pfelt> ah. basically yes
[19:33:16 CEST] <durandal_1707> and when it stops you want it to pick another url?
[19:33:43 CEST] <durandal_1707> use something like concat filter before hstack
[19:35:32 CEST] <pfelt> would that only allow a "stream swap" once?
[19:36:20 CEST] <pfelt> ie: i would start the stream on /tmp/pipe1 and then start the new stream on /tmp/pipe2, then i'd kill the stream going to /tmp/pipe1 and it'll move to the other
[19:36:46 CEST] <pfelt> (if concat is like unix 'cat')
[19:37:03 CEST] <durandal_1707> yes, concatenate streams
[19:37:25 CEST] <pfelt> and if i wanted to "stream swap" many times?
[19:37:53 CEST] <durandal_1707> just add such entries into filter args
[19:38:12 CEST] <durandal_1707> read filter doc for details
[19:38:32 CEST] <durandal_1707> I guess it should be possible
[20:00:59 CEST] <moparisthebest> I have h264 video in a transport stream (.ts) and I want to convert it to mkv, but it's crashing, is there some flags I could use or something?
[20:01:16 CEST] <moparisthebest> ffmpeg -i in.ts -vcodec copy -acodec copy -f matroska out.mkv
[20:01:31 CEST] <moparisthebest> is the exact commmand I'm using, I can watch the .ts fine in VLC and Kodi
[20:03:04 CEST] <moparisthebest> yes building the output log now
[20:04:58 CEST] <moparisthebest> http://pastebin.com/BSWZnsaW is the command + output
[20:11:43 CEST] <moparisthebest> I tried adding -fflags +genpts as referenced here: https://trac.ffmpeg.org/ticket/1553 because the errors looked similarish, same error though
[20:12:36 CEST] <c_14> That plays fine in VLC/Kodi?
[20:12:39 CEST] <c_14> Does it play with ffplay?
[20:12:53 CEST] <moparisthebest> yes vlc/kodi, let me try ffplay
[20:13:11 CEST] <moparisthebest> same conversion results with an old ffmpeg version 2.3.git too I just tested
[20:14:45 CEST] <moparisthebest> yes it plays fine so far with ffplay, it's an hour long so I haven't watched the entire thing
[20:14:59 CEST] <moparisthebest> but conversion fails almost instantly so the problem is *probably* towards the beginning anyway?
[20:18:12 CEST] <moparisthebest> ok I used the keys to fast forward to almost the end in ffplay and it finished successfully
[20:18:55 CEST] <c_14> Can you try with a newer git build maybe? If it still doesn't work, make a ticket on trac with the full command output, that the file plays with ffplay and if you can a short sample of the file (cut the file as short as possible so that the error still shows up when running the command on the cut file, you should be able to use dd to cut the file)
[20:19:47 CEST] <moparisthebest> yep I can try those things thanks
[20:21:28 CEST] <moparisthebest> should I just build from git master or a particular tag or?
[20:24:55 CEST] <c_14> just build from git master, or use a static build
[20:24:57 CEST] <c_14> http://johnvansickle.com/ffmpeg/
[20:25:44 CEST] <moparisthebest> binaries over http, I feel like I'm back running windows again :)
[20:34:15 CEST] <furq> does your package manager not use http
[20:34:34 CEST] <moparisthebest> sure but it verifies packages with pgp
[20:34:50 CEST] <moparisthebest> that website has an md5 file also served over the same http with which to 'verify' files :)
[20:38:43 CEST] <moparisthebest> my build from master is still going, an attempt with the johnvansickle build crashes the same way, and also crashes on a 5mb snip from the file made with dd
[20:43:52 CEST] <moparisthebest> it looks like it might be https://trac.ffmpeg.org/ticket/3339
[20:45:31 CEST] Action: c_14 isn't so sure. It looks like it's having issues with the h264 bitstream. It could be an amalgamation of issues though
[20:49:53 CEST] <moparisthebest> well I found something from that ticket that works...
[20:50:19 CEST] <moparisthebest> ffmpeg -i in.ts -vcodec copy -acodec copy out.mp4
[20:50:19 CEST] <moparisthebest> ffmpeg -i out.mp4 -vcodec copy -acodec copy out.mkv
[20:50:29 CEST] <moparisthebest> that gets me from in.ts to out.mkv with no errors... :/
[20:51:12 CEST] <moparisthebest> so it's something in the ts -> mkv code that doesn't get triggered in the ts -> mp4 or mp4 -> mkv code?
[20:51:46 CEST] <moparisthebest> it's not particularly something I want to script either hehe
[20:52:10 CEST] <JEEB> the timestamp business with mpeg-ts can get rather funky
[20:52:11 CEST] <sciss> hi there -- I can't get the eq filter to work (http://ffmpeg.org/ffmpeg-filters.html#eq) Thought it must be `ffmpeg -i in.mp4 -vf "eq=gamma=0.5" out.mp4` but all I get is `No such filter: 'eq'`. Just built from master HEAD. Any ideas?
[20:52:42 CEST] <JEEB> I've seen that both FFmpeg and VLC seem to fix that stuff somewhere around the decoder
[20:52:56 CEST] <JEEB> while when you remux... you can get funky results
[20:53:00 CEST] <durandal_1707> sciss: need gpl flag
[20:53:07 CEST] <JEEB> I will have to check my sample with ts=>mkv though
[20:53:10 CEST] <moparisthebest> it makes sense then that it plays just fine
[20:53:16 CEST] <sciss> @durandal_1707 - while running or while building/compiling?
[20:53:19 CEST] <moparisthebest> because it isn't making a mkv
[20:53:29 CEST] <JEEB> moparisthebest: more like playback decodes
[20:53:43 CEST] <JEEB> and the decoder is handling timestamp messiness
[20:53:49 CEST] <durandal_1707> sciss: to configure
[20:53:49 CEST] <moparisthebest> so should I create a new issue or add my findings to https://trac.ffmpeg.org/ticket/3339 ?
[20:54:34 CEST] <JEEB> is the issue the same?
[20:54:39 CEST] <JEEB> if yes, upload a sample and poke that ticket
[20:54:55 CEST] <sciss> @durandal_1707: Just to be sure I understand - so I remove, clean and run again `./configure --enable-gpl`?
[20:55:09 CEST] <moparisthebest> maybe it's the same JEEB , the error is similarish
[20:55:39 CEST] <durandal_1707> sciss: yes, something like that
[20:55:42 CEST] <JEEB> if it's just similar'ish as opposed to being the same, then upload a sample and open a new ticket :)
[20:55:45 CEST] <sciss> Ok thank will try
[20:55:58 CEST] <JEEB> it will be marked duplicate if it is such :P
[20:56:03 CEST] <moparisthebest> I don't know how to tell JEEB http://pastebin.com/BSWZnsaW vs https://trac.ffmpeg.org/ticket/3339 ?
[20:56:43 CEST] <JEEB> hmm, de1a0d4 - let's see how old that is
[20:57:08 CEST] <JEEB> ok, not too old
[20:58:51 CEST] <JEEB> moparisthebest: seems similar enough
[20:59:23 CEST] <JEEB> upload a sample in a way that it can be easily grabbed and post there together with the log you originally pastebin'd (if possible without cutting anything out if you have done so)
[21:01:12 CEST] <moparisthebest> meanwhile I'll write some bash so if ffmpeg exit status is not 0, it'll convert to mp4 and then to mkv, and cry a little bit :)
[21:01:54 CEST] <JEEB> I'm having even more fun with live input :)
[21:02:14 CEST] <JEEB> although I guess I could try fragmented mp4
[21:02:17 CEST] <JEEB> for shits and giggles
[21:02:20 CEST] <moparisthebest> these .ts files are coming from a tuner
[21:13:53 CEST] <moparisthebest> ok JEEB c_14 I made a comment to an existing issue here: https://trac.ffmpeg.org/ticket/3339#comment:19
[21:14:12 CEST] <moparisthebest> I don't suppose there is any syntax to do the ts -> mp4 -> mkv in one ffmpeg command is there? :/
[21:17:36 CEST] <cons0l3> hi, I have a 60min file.avi grabbed with virtualdub via firewire from videocam. it contains the typical frame and audio errors (e.g. sounds and video sometime seem to be in slow motion and then pick up in speed). When seeking to a timestamp the precision of actually hitting the seeked timestamp degrades the further to the end of the file i get. The more errors I have in the file, the bigger the seeking error. what can i do, to compensa
[21:18:30 CEST] <moparisthebest> ah my build finished, so also just tested current master and it still fails the same way
[21:19:15 CEST] <cons0l3> ^ the degradation of seek error. i want to cut the files on detected scenes.
[21:21:46 CEST] <cons0l3> the seeking is performed by ffmpeg -ss 10:00.00 -i input.avi -to 11:00.00 output.avi
[21:33:58 CEST] <sciss> hi there -- I'm transcoding an mp4/h264 with a video filter. I can't get the output quality to increase. I try `ffmpeg -i in.mp4 -c:v libx264 -crf 18 -vf "eq=gamma=0.5" -c:a copy out.mp4` but it says `Unrecognized option 'crf'.`
[21:35:44 CEST] <klaxa> what ffmpeg are you running?
[21:37:08 CEST] <sciss> I just compiled from git/master
[21:37:19 CEST] <sciss> I added --enable-gpl to get the gamma filter
[21:37:48 CEST] <furq> pastebin the full command and output
[21:38:04 CEST] <sciss> That's the full command
[21:38:35 CEST] <c_14> >and output
[21:38:56 CEST] <sciss> http://pastebin.com/raw/K91Acsht
[21:39:42 CEST] <c_14> you didn't build with libx264
[21:39:51 CEST] <c_14> add --enable-libx264 to configure
[21:40:14 CEST] <sciss> Ok. Is there a page that lists _all_ I should add to configure, coz I'm rebuilding the third time now. Seems defaults are not sensible
[21:40:29 CEST] <c_14> Depends, what do you want?
[21:40:44 CEST] <furq> sciss: http://johnvansickle.com/ffmpeg/
[21:40:48 CEST] <furq> you could just use those builds
[21:40:53 CEST] <sciss> I want all codecs and filters. Possibly not the non-free ones (unless this particular example requires non-free code)
[21:41:04 CEST] <furq> ./configure --help | grep enable
[21:41:09 CEST] <sciss> Ok
[21:42:15 CEST] <c_14> If you want to encode all codecs you'll have to add support for various third party encoders, decode support should be default for most things. There's a few filters that need some libraries, notably fontconfig/freetype/libass
[21:43:06 CEST] <sciss> Thanks
[21:43:08 CEST] <furq> opus is the only popular codec which needs a library for decoding that comes to mind
[21:43:27 CEST] <JEEB> no longer
[21:43:29 CEST] <furq> those static builds are probably good enough though
[21:43:31 CEST] <furq> oh really
[21:43:35 CEST] <JEEB> there's libavcodec opus decoder now
[21:43:39 CEST] <JEEB> it was made for standardization
[21:43:41 CEST] <furq> neat
[21:43:47 CEST] <JEEB> because EBU required multiple implementations
[21:43:53 CEST] <JEEB> (European Broadcasting Union)
[21:44:38 CEST] <furq> also, was libdcadec support removed
[21:44:51 CEST] <JEEB> because libdcadec became the new dcadec
[21:45:27 CEST] <furq> i have no intention of using it, i just noticed my build script was broken
[21:45:34 CEST] <furq> i figured maybe it'd been folded in
[21:45:38 CEST] <JEEB> yes
[21:45:49 CEST] <JEEB> its author was happy to replace the old dcadec
[21:46:22 CEST] <furq> i guess i'll get rid of that then
[21:46:58 CEST] <moparisthebest> here is how I worked around the ts -> mkv bug https://www.moparscape.org/paste/?eb069a246f9b0895#Y43JW+IfnOWTeOHbB4Iv//rV… :(
[21:47:01 CEST] <pfelt> is there any sort of filter that would say something like "[0:v][1:v]IfThen [output]" where it would take frames from stream 1 only if there were no available frames from stream 1 ?
[21:47:10 CEST] Action: pfelt doesn't see such a thing in ffmpeg filters docs
[21:49:24 CEST] <cons0le> hi, sorry for reasking, but irc glitched out. how do i compensate seek precession degradation in a dv grabbed file? i currently try to ffmpeg -i input.avi -ss 59:00.0 -t 1:00.0 -c copy output.avi, but it misses the seeked time by several seconds.
[21:51:04 CEST] <furq> cons0le: -ss and -t with -c copy will cut at the nearest keyframe
[21:51:10 CEST] <furq> if that's not precise enough then you'll need to reencode
[21:53:06 CEST] <cons0le> furq: can a keyframe be 7 and more seconds away? the video is encoded in dvvideo as it is grabbed directly from dv-cam with virtualdub (type2).
[21:53:41 CEST] <cons0le> why to i hit the timemark very accuratly in the beginning and at the end it gets worst and worst?
[22:23:38 CEST] <BtbN> keyframes can be way more than 7 seconds apart
[22:49:54 CEST] <blue_misfit> hey guys - what are best practices for encoding UHD VP9 using 2 pass CBR? I saw some documentation here http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide - wondering if it's out of date
[22:50:29 CEST] <blue_misfit> if it matters, I want to have good decoding performance
[22:53:50 CEST] <pfelt> is there any sort of filter that would say something like "[0:v][1:v]IfThen [output]" where it would take frames from stream 1 only if there were no available frames from stream 1 ? i was kinda hoping to display the color bars if one of my inputs was hung
[22:59:12 CEST] <durandal_170> no, but I could write it
[23:02:10 CEST] <TD-Linux> blue_misfit, that guide is still fine. in particular the changes I usually suggest tend to hurt decoding performance
[23:06:23 CEST] <blue_misfit> TD-Linux, thanks! :)
[23:06:49 CEST] <blue_misfit> how's VBV with VP9?
[23:07:06 CEST] <blue_misfit> I may need to do CBR for one of my streams
[23:07:45 CEST] <TD-Linux> it works though the configuration is a bit confusing
[23:08:06 CEST] <blue_misfit> -minrate 1M -maxrate 1M -b:v 1M ?
[23:09:00 CEST] <TD-Linux> that should work, but I have not personally tried a very constrained encode
[23:09:19 CEST] <blue_misfit> gotcha. I'd be looking to do pseudo CBR (i.e. no padding, but constrained maxrate)
[23:09:38 CEST] <blue_misfit> progressive download experience
[23:10:17 CEST] <TD-Linux> yeah. you can probably constrain the VBR mode to do what you want
[23:10:37 CEST] <blue_misfit> okay, and getting 2 pass working is as simple as specifying -pass 1 and then -pass 2?
[23:10:48 CEST] <TD-Linux> yes.
[23:36:12 CEST] <blue_misfit> TD-Linux, looks like in my case it's undershooting by about 50% on the bitrate target. It's a 45 second clip but it's 2880x2800p30 at 4 Mbps so I'm surprised it undershoots by that much. Is this expected?
[23:36:53 CEST] <blue_misfit> some definite loss of quality as well so I don't think I'm saturating :)
[23:37:14 CEST] <blue_misfit> oh, and this is unrestricted ABR
[23:38:58 CEST] <TD-Linux> two pass as well, correct?
[23:39:01 CEST] <blue_misfit> yep
[23:39:15 CEST] <blue_misfit> did another encode on the same content targeting 15 Mbps and it came out as 8.5 :D
[23:39:29 CEST] <TD-Linux> yeah wow that's pretty bad. this is without -minrate right?
[23:39:30 CEST] <blue_misfit> I'm using a zeranoe ffmpeg build from last month, give or take
[23:39:33 CEST] <blue_misfit> yep
[23:40:12 CEST] <blue_misfit> it looks pretty good honestly, but significantly worse than x265 encodes with the same targets (which actually hit their targets very well :))
[23:40:17 CEST] <TD-Linux> try adding a minrate and see if it helps. there are some more specific options to control this in vpxenc, not sure how they all map to ffmpeg options
[23:40:22 CEST] <blue_misfit> ok
[23:40:32 CEST] <blue_misfit> does RC in vp9 play nicely with threads?
[23:41:09 CEST] <TD-Linux> yes it should be fine with tile threads
[23:41:59 CEST] <blue_misfit> pass 1: -threads 8 -speed 4 -tile-columns 6 -frame-parallel 1
[23:42:09 CEST] <blue_misfit> pass 2: -threads 8 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25
[23:42:23 CEST] <blue_misfit> all straight from that best practices dog
[23:42:25 CEST] <blue_misfit> doc*
[23:42:31 CEST] <TD-Linux> yeah should be fine. note that frame-parallel doesn't give much speedup anymore
[23:43:56 CEST] <blue_misfit> I'll try without that first, and see if it makes any difference
[23:45:47 CEST] <TD-Linux> I don't think frame-parallel will affect rate control anyway, just a side comment.
[23:49:14 CEST] <blue_misfit> k
[23:49:22 CEST] <kepstin> huh, changing the auto-alt-ref and lag-in-frames seems like something that might mess up the stats for the pass1 vs pass2, tho? or does it?
[23:51:05 CEST] <blue_misfit> kepstin, not sure - the best practices doc said to do it this way
[00:00:00 CEST] --- Tue Apr 12 2016
1
0
[00:12:50 CEST] <michaelni> durandal_1707, theres nothing in GSoCs web interface to pass students ATM that i know of, theres only a "ignore" and a "star" thing, neither is documented AFAIK
[00:27:40 CEST] <michaelni> iam just assuming that "star" means something like accept and "ignore" clearly means what it says and we use "ignore" for "spam"
[00:33:29 CEST] <durandal_1707> I can't add star
[02:34:25 CEST] <kierank> how do I mark someone as accept
[02:34:50 CEST] <kierank> star thing doesn't work
[13:34:16 CEST] <cone-314> ffmpeg 03Michael Niedermayer 07master:ee7a642b0e5d: avformat/mpegts: Check adaption field control in analyze() more instead of transport_error_indicator
[13:34:16 CEST] <cone-314> ffmpeg 03Michael Niedermayer 07master:38a6242b271f: avformat/mpegts: Remove unused argument from analyze()
[14:54:57 CEST] <gerion> hi, can somebody say what error number -541478725 mean?
[14:55:16 CEST] <gerion> if get this as return value of ff_request_frame in a filter
[14:56:04 CEST] <gerion> doc says only something about AVERROR(EOF) and AVERROR(EAGAIN) but none of this has the high number
[14:57:40 CEST] <gerion> btw the number seems to be unique to ffmpeg (the results from google are always ffmpeg related) :)
[14:59:08 CEST] <nevcairiel> that is AVERROR_EOF
[14:59:15 CEST] <nevcairiel> note that EOF uses AVERROR_EOF, not AVERROR(EOF)
[14:59:18 CEST] <nevcairiel> important difference
[14:59:45 CEST] <gerion> oh ok
[14:59:50 CEST] <gerion> i see, thx
[15:00:14 CEST] <jkqxz> Look at libavutil/error.h - the numbers are kinda hard to search.
[15:01:00 CEST] <kierank> I'm sorry that you are using lavfi from the api
[15:01:46 CEST] <gerion> jkqxz: the problem is the output with %d, but the doc says also AVERROR_EOF have not see it correctly
[15:02:44 CEST] <nevcairiel> dont we have a function to print you an error string
[15:07:07 CEST] <gerion> hmm now I undertand the error, problem is: my signature filter is multiinput, but input can have different length, the relevant function is request frame
[15:07:58 CEST] <gerion> for now i had:
[15:07:58 CEST] <gerion> iterate over all inputs {
[15:07:58 CEST] <gerion> ret = ff_request_frame(ctx->inputs[i]);
[15:07:58 CEST] <gerion> }
[15:07:59 CEST] <gerion> return ret;
[15:08:08 CEST] <gerion> this only returns the last error code
[15:08:37 CEST] <gerion> but if I add "if (ret < 0) return ret;" in the for loop
[15:09:19 CEST] <gerion> the filter fails in calling filter_frame given you have a short input[0] video and a longer input[1] video
[15:09:56 CEST] <gerion> do you know a way to honor the return values without making the filter useless?
[15:10:55 CEST] <gerion> the reason the filter fails is that it return EOF for the first input and then return immediately
[15:12:29 CEST] <gerion> my solution would be something like recording the returnvalue for each input, if all inputs are EOF return EOF, if all inputs are 0 return 0, what should I do with AVERROR(EAGAIN)?
[15:23:54 CEST] <Daemon404> energized
[15:24:00 CEST] <Daemon404> see if i can fix that weird mkv thing
[15:24:15 CEST] <Daemon404> other than plan, i plan to merge today, i think
[15:24:31 CEST] <Daemon404> michaelni wm4 nevcairiel ubitux ^
[15:26:20 CEST] <wm4> sure
[15:28:38 CEST] <Daemon404> 11 hrs of sleep and 2 espresso later im pretty sure i can fix mkv
[15:29:08 CEST] Action: Daemon404 adds roughly 50 printfs to ffmpeg.c
[15:40:01 CEST] <cone-314> ffmpeg 03Carl Eugen Hoyos 07master:7e1e25c2dced: lavf/avio: Remove linebreak from https warning.
[15:46:45 CEST] <Daemon404> encoder <- type:video frame_pts:21 frame_pts_time:0.84 time_base:1/25 pkt_duration:3600
[15:46:48 CEST] <Daemon404> encoder -> type:video pkt_pts:21 pkt_pts_time:0.84 pkt_dts:21 pkt_dts_time:0.84 pkt_duration:0
[15:46:53 CEST] <Daemon404> so the encoder is nulling the pkt duration
[15:47:06 CEST] <Daemon404> O_o
[15:50:58 CEST] <rcombs> which encoder
[15:51:47 CEST] <Daemon404> mpeg4
[15:51:50 CEST] <Daemon404> and h264
[15:52:45 CEST] <Daemon404> apparently...
[15:52:45 CEST] <rcombs> not particularly surprising
[15:53:02 CEST] <rcombs> since they delay+reorder
[15:53:44 CEST] <Daemon404> it didnt happen pre-codecpar
[15:55:28 CEST] <rcombs> libx264.c doesn't appear to touch pkt_duration directly, so I'd imagine the value was automatically filled by lavc with the duration of the packet being passed in (i.e. not necessarily correct due to delay)?
[15:55:50 CEST] <rcombs> or was there some magic to find the right packet params out of a queue by pts?
[15:56:07 CEST] <Daemon404> i have no idea, looking into it further atm
[15:57:15 CEST] <Daemon404> hmm looks like it happens with old ffmpeg master too??
[15:57:28 CEST] <Daemon404> maybe ffmpeg.c re-sets it somewhere if (magic)
[15:57:55 CEST] <JEEB> wee
[15:58:32 CEST] <Daemon404> let's see what master has
[15:59:15 CEST] <Daemon404> hmmm so ffmpeg.c passes muxer 0 duration too!
[15:59:17 CEST] <Daemon404> in master
[15:59:26 CEST] <Daemon404> so wtf, the muxer used to make up some duration but no longer does?
[16:02:28 CEST] <Daemon404> also we have so many debug flags...
[16:02:42 CEST] <JEEB> like debugts?
[16:02:44 CEST] <Daemon404> -loglevel debug, -debugts, -debug (which does everything but ts) and -fdebug ts
[16:02:54 CEST] <Daemon404> they all do slightly different things
[16:02:56 CEST] <JEEB> yeah
[16:04:26 CEST] <rcombs> https://xkcd.com/927/ we need to develop one universal debug flag that covers everyone's use cases
[16:11:31 CEST] <Daemon404> while that xkcd is usually relevant, not in this case imo
[16:19:16 CEST] Action: rcombs shrugs
[16:19:41 CEST] <Daemon404> ok i figured it out... eugh
[16:27:39 CEST] <Daemon404> woo ... fixed it.
[16:27:43 CEST] <JEEB> \o/
[16:28:49 CEST] <Daemon404> just gotta run fate
[16:34:54 CEST] <nevcairiel> um Daemon404, are you sure about this
[16:34:56 CEST] <nevcairiel> if (!st->codec->time_base.num && st->codec->time_base.num) {
[16:35:00 CEST] <nevcairiel> this looks mighty wrong =p
[16:35:35 CEST] <nevcairiel> might as well delete the entire block
[16:36:41 CEST] <rcombs> kek
[16:36:49 CEST] <rcombs> nice unreachable
[16:39:25 CEST] <Daemon404> nevcairiel, revert it then
[16:39:30 CEST] <Daemon404> that wasnt my fix (which is unpushed)
[16:39:33 CEST] <Daemon404> i just happened to notice that
[16:39:41 CEST] <Daemon404> ill push a revetr
[16:39:57 CEST] <nevcairiel> oh well, i thought this was supposed to fix this
[16:40:06 CEST] <nevcairiel> which would've been some mad side effect
[16:40:06 CEST] <nevcairiel> :;D
[16:40:23 CEST] <Daemon404> lol
[16:40:40 CEST] <Daemon404> ill show my fix for the mkv thing once i pass fate
[16:40:42 CEST] <Daemon404> which i need to rerun
[16:40:54 CEST] <nevcairiel> wonder when this compat block can go though, should check dates when it was deprecated
[16:40:55 CEST] <Daemon404> because i bet teh new failrues were from the change i just revert
[16:41:16 CEST] <Daemon404> which would indicate that compat used still affects fate
[16:41:17 CEST] <nevcairiel> ffmpeg.c probably still uses it in some situations though
[16:41:19 CEST] <Daemon404> yeah
[16:41:38 CEST] <nevcairiel> i tried to read some of its processing flow earlier, but its just so confusing
[16:41:47 CEST] <nevcairiel> mixing AVStreams with its own stream objects and all sorts of weird properties
[16:42:33 CEST] <Daemon404> i spent over a week in this code, man
[16:42:37 CEST] <Daemon404> youre preaching to the choir
[16:42:44 CEST] <kierank> are there any ffv1 samples anywhere
[16:42:55 CEST] <Daemon404> kierank, ask dave rice? :P
[16:43:01 CEST] <kierank> small ones
[16:43:05 CEST] <kierank> for fuzzing
[16:44:26 CEST] <kierank> found one i think
[16:47:06 CEST] <Daemon404> i wish fate didnt have so many vsynth
[16:47:11 CEST] <Daemon404> takes forever to run
[16:47:14 CEST] <Daemon404> with each change
[16:47:23 CEST] <nevcairiel> i never thought vsynth was a slow part for me
[16:47:58 CEST] <Daemon404> looks like this fix also makes some of the old flv hashes match
[16:48:06 CEST] <nevcairiel> i wonder if i could make a sort of breakdown of how long the tests take individually and make some sort of stats
[16:48:07 CEST] <Daemon404> (they were different, but not wrong.)
[16:48:14 CEST] <Daemon404> (since the code i just fixed was for fixing wrong crap)
[16:49:06 CEST] <nevcairiel> matching old hashes is always nice
[16:50:02 CEST] <Daemon404> it still bothers me that we call teh compute pkt duration function in mux.c, but thats unrelated to this merge
[16:51:49 CEST] <nevcairiel> i wish we could reliably lock down git for a couple hours to get a final squashed and rebased version, give it a final read through for an hour without having to worry about rebasing it again later
[16:53:29 CEST] <Daemon404> its not much a problem if the changes are all unrelated
[16:53:42 CEST] <Daemon404> but i dunno how one would manage that with ffmpeg
[16:53:45 CEST] <nevcairiel> i dont even know how you rebase the merge, that was something i always had trouble with
[16:53:46 CEST] <Daemon404> locking, that is
[16:53:56 CEST] <Daemon404> i do it in an old-school way
[16:54:09 CEST] <Daemon404> git diff HEAD^..HEAD > merge.diff
[16:54:12 CEST] <nevcairiel> lol
[16:54:13 CEST] <Daemon404> git reset --hard HEAD^
[16:54:14 CEST] <Daemon404> git pull
[16:54:19 CEST] <Daemon404> git merge -s ours --log <hash>
[16:54:22 CEST] <nevcairiel> guess that works
[16:54:23 CEST] <Daemon404> patch -p1 < merge.diff
[16:54:28 CEST] <Daemon404> fix by hand
[16:54:29 CEST] <Daemon404> and amend
[16:54:36 CEST] <Daemon404> it made rebase this SO much easier
[16:54:40 CEST] <Daemon404> git itself does it so terribly
[16:54:40 CEST] <nevcairiel> there was like one new demuxer a day or so ago
[16:54:52 CEST] <nevcairiel> i still dont know why it cant just rebase the merge like any other commit
[16:54:53 CEST] <Daemon404> right
[16:54:55 CEST] <nevcairiel> why is that so hard
[16:55:05 CEST] <Daemon404> yeah i dunno
[16:56:26 CEST] <Daemon404> but yeah, i often find diff/patch easier to use taht git itself
[16:56:28 CEST] <Daemon404> i use them a *lot*
[16:56:31 CEST] <Daemon404> than*
[16:56:42 CEST] <nevcairiel> the only part i had such troubles with is merging for ffmpeg
[16:56:48 CEST] <nevcairiel> everything else i can do with git
[16:56:59 CEST] <Daemon404> merging in general, is like that
[16:57:04 CEST] <nevcairiel> and for the simple merges I just used git rerere
[16:57:14 CEST] <nevcairiel> but that doesnt work in such a huge merge
[16:57:15 CEST] <Daemon404> git rerere works... very weirdly
[16:57:23 CEST] <Daemon404> and cant handle ammends to a merge
[16:57:33 CEST] <Daemon404> itll use the old conflic resolutions
[16:57:39 CEST] <Daemon404> pre-amend
[16:57:43 CEST] <Daemon404> which sucks when fixign stuff
[16:57:50 CEST] <nevcairiel> hence simple merges
[16:58:06 CEST] <nevcairiel> it helps somewhat, but isnt the universal answer
[16:58:16 CEST] <Daemon404> it's also SLOW
[16:58:17 CEST] <Daemon404> for me anyway
[16:58:29 CEST] <nevcairiel> merging and rebasing got super fast in some recent git update
[16:58:37 CEST] <Daemon404> interesting
[16:58:41 CEST] <nevcairiel> was it 2.7
[16:58:43 CEST] <nevcairiel> maybe
[17:01:31 CEST] <Daemon404> ok pushed fix
[17:01:45 CEST] <Daemon404> only fate chanegs were making some old flv hashes match
[17:02:18 CEST] <Daemon404> shall i rebase on master now?
[17:02:24 CEST] <Daemon404> and push to a branch for final inspection?
[17:02:29 CEST] <nevcairiel> sure
[17:03:00 CEST] <nevcairiel> like i said a few demuxer changes in the last week that need adapting, but nothing too big
[17:03:26 CEST] <nevcairiel> also two new demuxers
[17:03:32 CEST] <nevcairiel> but trivial ones
[17:06:32 CEST] <Daemon404> yes
[17:06:36 CEST] <Daemon404> ill squash those in too
[17:06:38 CEST] <Daemon404> should be easy
[17:07:35 CEST] <nevcairiel> did someone ever update the lib* based demuxers, i dont think i checked
[17:08:00 CEST] <nevcairiel> looks like they are
[17:10:16 CEST] <Daemon404> nevcairiel, yes i did them
[17:10:41 CEST] <Daemon404> nevcairiel, yes fixing all the new changes was easy
[17:10:55 CEST] <Daemon404> make libavformat/libavformat.a and watch for new warnigns -> fix
[17:11:21 CEST] <nevcairiel> thats how i originally went through the files
[17:11:28 CEST] <nevcairiel> also why lib* stuff didnt get any love from me =p
[17:20:01 CEST] <Daemon404> good news: no fate failures after rebase
[17:20:40 CEST] <wm4> don't think, push
[17:20:57 CEST] <nevcairiel> did you push it to github=
[17:21:53 CEST] <Daemon404> i am doing this now
[17:24:19 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/tree/codecpar_rebase_part_two
[17:27:40 CEST] <nevcairiel> do you want to push tonight then?
[17:27:48 CEST] <Daemon404> i would like to, yes.
[17:27:57 CEST] <nevcairiel> ok
[17:28:10 CEST] <nevcairiel> i'll scroll through the diff and see if i find something obvious left
[17:28:13 CEST] <Daemon404> ok
[17:28:19 CEST] <Daemon404> you cant on teh githbu ui though
[17:28:21 CEST] <Daemon404> it's too long
[17:28:24 CEST] <Daemon404> A+ web ui
[17:28:48 CEST] <nevcairiel> yeah
[17:29:00 CEST] <nevcairiel> and if you try to use the .patch url, you get the original commit from anton for some reason
[17:29:06 CEST] <Daemon404> wtf?
[17:29:15 CEST] <nevcairiel> i used the .diff url now to download a full diff
[17:29:24 CEST] <Daemon404> that's just so odd
[17:29:46 CEST] <Daemon404> ive always used .diff and .patch interchangeably
[17:29:48 CEST] <Daemon404> since everyone used both before git
[17:29:51 CEST] <Daemon404> for diff/patch
[17:30:07 CEST] <nevcairiel> diff is just an ordinary diff -u
[17:30:10 CEST] <nevcairiel> patch is weird
[17:30:17 CEST] <nevcairiel> it gives you a git-format-patch thing usually
[17:30:29 CEST] <kierank> ok, so what libs need removal?
[17:30:35 CEST] <Daemon404> yeah but thats a github-only distinction
[17:30:37 CEST] <nevcairiel> but if you try to use it say on a range of commits, it just concats the format-patches one after another
[17:30:44 CEST] <Daemon404> yes
[17:30:53 CEST] <nevcairiel> while diff gives you an overall diff
[17:30:53 CEST] <kierank> faac?
[17:31:10 CEST] <Daemon404> faac has no uses afaict
[17:31:54 CEST] <nevcairiel> AV_RB32(par->extradata+0); .. who writes stuff like that =p
[17:32:18 CEST] <Daemon404> thats not from us though
[17:32:22 CEST] <Daemon404> that was there pre-merge
[17:32:25 CEST] <nevcairiel> i know
[17:32:28 CEST] <nevcairiel> but still +0
[17:32:30 CEST] <Daemon404> yeah
[17:32:31 CEST] <Daemon404> i dunno
[17:34:05 CEST] <wm4> why not
[17:34:21 CEST] <wm4> might look nicer if there are other offsets
[17:34:46 CEST] <Daemon404> 'if'
[17:47:07 CEST] <wm4> --enable-libflite enable flite (voice synthesis) support via libflite [no]
[17:47:11 CEST] <wm4> we have such a thing?
[17:47:29 CEST] <wm4> lol it's a libavfilter source
[17:47:57 CEST] <JEEB> wow
[17:51:35 CEST] <JEEB> btw, was aacplus already removed?
[17:51:50 CEST] <JEEB> so that we would only have fdk-aac and the internal one
[17:53:02 CEST] <wm4> yes aacplus is removed
[17:54:26 CEST] <Daemon404> btw i cant wait for half of lavf to show my name in git blame after this merge
[17:54:50 CEST] Action: Daemon404 suspects a lot of blame will be aimed at him
[17:56:14 CEST] <JEEB> :D
[18:01:13 CEST] <wm4> git should totally have support for N author fields
[18:01:52 CEST] <Daemon404> iirc svn did
[18:01:53 CEST] <Daemon404> kinda
[18:25:57 CEST] <nevcairiel> anyone wanna place bets how long after push carl asks for revert?
[18:27:04 CEST] <Daemon404> 16:14 < Daemon404> wm4, do you want to start a pot on how long it takes for carl to demand a revert?
[18:27:07 CEST] <Daemon404> fro m2 or so days ago
[18:27:12 CEST] <Daemon404> ;)
[18:27:16 CEST] <nevcairiel> ahah
[18:27:20 CEST] <Daemon404> \
[18:29:07 CEST] <nevcairiel> there is q uite certainly still some hidden problems left somewhere, but thats expected of such a huge change
[18:30:08 CEST] <Daemon404> well yes
[18:30:22 CEST] <Daemon404> but what do you expect?
[18:30:22 CEST] <Daemon404> "write bug free code every time"?
[18:30:22 CEST] <wm4> of course
[18:30:38 CEST] <wm4> without doubt there will be some fallout
[18:30:59 CEST] <Daemon404> all directly aimed at me no doubt
[18:31:29 CEST] <nevcairiel> i never got angry mails for merged breakage, you must somehow attract that more
[18:31:57 CEST] <nevcairiel> btw there is still usage of st->codec in sdp speex code
[18:32:05 CEST] <nevcairiel> unfixable, too, no clue what to make of that
[18:32:28 CEST] <nevcairiel> it needs to know rather codec specific information
[18:33:17 CEST] <nevcairiel> anyway carl will be most upset about information loss in ffmpeg.c stream listings, like ref frame count, closed caption presence, etc
[18:33:30 CEST] <nevcairiel> because the auto-probing no longer exports that
[18:33:43 CEST] <wm4> yeah, we discussed the speex/sdp thing away
[18:34:02 CEST] <wm4> and the stream listings come from libavformat/dump.c
[18:34:14 CEST] <wm4> IMO it's a given that these can't be as detailed anymore
[18:34:25 CEST] <nevcairiel> did we ever do something about the flac bitdepth loss?
[18:34:30 CEST] <Daemon404> [17:31] <@nevcairiel> i never got angry mails for merged breakage, you must somehow attract that more <-- he doesnt like me, is why
[18:34:31 CEST] <wm4> what ffmpeg.c really should do is decode a frame for each stream
[18:34:41 CEST] <nevcairiel> i personally would miss that as well, really
[18:34:57 CEST] <Daemon404> nevcairiel, i changed it to use coded rather than raw
[18:35:01 CEST] <Daemon404> for flac it should still work
[18:35:11 CEST] <nevcairiel> changed where
[18:35:17 CEST] <nevcairiel> in the printout?
[18:35:21 CEST] <Daemon404> the bit tou added in matroska*c
[18:35:25 CEST] <nevcairiel> oh that
[18:35:34 CEST] <wm4> that one wasn't entirely clear
[18:35:35 CEST] <Daemon404> oh the dump.
[18:35:48 CEST] <Daemon404> we can probably add codedd depth printout in dump
[18:36:06 CEST] <Daemon404> i personally blame the lack of a 24bit format
[18:36:22 CEST] <nevcairiel> yeah well that is to blame
[18:37:03 CEST] <Daemon404> i more or less never use dump.c stuff
[18:37:03 CEST] <Daemon404> i use ffprobe like a sane person to get info
[18:37:06 CEST] <nevcairiel> i used that info myself in the demuxer to export that part of the stream information
[18:37:29 CEST] <nevcairiel> guess i'll see how to poke that when i update to codecpar
[19:25:44 CEST] <cone-277> ffmpeg 03Martin Vignali 07master:2dd7b46132e2: avcodec/exr: fix channel detection
[19:53:05 CEST] <cone-277> ffmpeg 03Martin Vignali 07master:b45d542ea625: fate/exr : add test for PXR24 Float and tile uncompress
[19:55:07 CEST] <cone-277> ffmpeg 03Paul B Mahol 07master:571aa7d25edc: avcodec/shorten: mark as AV_CODEC_CAP_SUBFRAMES
[19:56:46 CEST] <Daemon404> atomnuker, any way to make the native encoder faster/worse?
[19:56:56 CEST] <Daemon404> seems like the reason we cant remove faac is due to speed
[19:56:58 CEST] <nevcairiel> use the fast coder
[19:57:05 CEST] <nevcairiel> its absolutely terrible
[19:57:12 CEST] <Daemon404> worse or better than faac though
[19:57:16 CEST] <atomnuker> well the fast coder doesn't do rate control
[19:57:32 CEST] <Daemon404> lol ic
[19:57:46 CEST] <atomnuker> so the bitrate's going to be stuck at 400kbps ish
[19:58:00 CEST] <atomnuker> also it's not particularly faster than twoloop
[19:58:06 CEST] <Daemon404> i mean
[19:58:08 CEST] <Daemon404> the example he gave
[19:58:14 CEST] <Daemon404> the internal aac encoder is still 25-30x realtime
[19:58:21 CEST] <Daemon404> so personally i wouldnt even give a shit
[19:58:24 CEST] <JEEB> lol
[19:58:24 CEST] <atomnuker> I thought we got rid of faac a long time ago
[19:58:28 CEST] <JEEB> nah
[19:58:38 CEST] <JEEB> aacplus was the one that was dropped first
[19:59:55 CEST] <wm4> Daemon404: but what about all those people who use an i386 as streaming server?
[20:00:43 CEST] <Daemon404> it still proabbly faster than realtime
[20:00:52 CEST] <Daemon404> my phone can probably do faster than real time N times over
[20:01:41 CEST] <atomnuker> faac is unstable, hasn't had any work done on it at all in who knows how many years, misses a ton of features, IIRC some decoder complain about its bitstream, etc
[20:02:03 CEST] <Daemon404> reply as such
[20:02:10 CEST] <Daemon404> nothing happens if you omly say it on irc
[20:02:18 CEST] <atomnuker> was
[20:02:19 CEST] <JEEB> yeah
[20:02:31 CEST] <Daemon404> "it's fast because it's bad" afaict
[20:02:32 CEST] <Daemon404> ;)
[20:02:53 CEST] <Daemon404> our internal aac encoder about matches fdk's speed fwiw
[20:27:14 CEST] <Daemon404> lol that wma 'support'
[20:27:27 CEST] <Daemon404> ive had to add hacks at work so ffmpeg doesnt try and use the 'decoder'
[20:27:42 CEST] <Daemon404> (failing is better than weirdly silent audio)
[21:01:58 CEST] <Daemon404> nevcairiel, how goes merge reading
[21:02:38 CEST] <nevcairiel> nothing crazy so far
[21:02:55 CEST] <Daemon404> \o/
[21:37:57 CEST] <cone-277> ffmpeg 03Jakub Stachowski 07master:60b75186b2c8: avcodec/wmalosslessdec: do not discard last frame
[21:51:03 CEST] <durandal_1707> if codecpar doesn't happen I will start cherry picking interesting commits from libav
[21:52:34 CEST] <JEEB> it's pretty much happening
[21:52:49 CEST] <JEEB> it was just rebased and should be merged soon unless nev finds some extra issues
[21:53:52 CEST] <nevcairiel> its probably fine as it is now if Daemon404 wants to merge, always things we have to fix over the next week
[21:56:35 CEST] <Daemon404> \o/
[21:56:54 CEST] <Daemon404> shall i?
[21:57:01 CEST] <Daemon404> after a fate run
[21:57:33 CEST] <durandal_1707> after Carl goes to sleep :p
[21:58:06 CEST] <Daemon404> heh
[22:00:06 CEST] <durandal_1707> oh he is here
[22:01:28 CEST] <Daemon404> dont deliberately goad someone, only bad things happen
[22:06:03 CEST] <JEEB> oh kierank finally brought up the fact that faac is nonfree
[22:06:53 CEST] Action: Daemon404 is keeping distance from aac stuff
[22:06:59 CEST] <Daemon404> 10-foot pole for me right now
[22:07:51 CEST] <JEEB> yeah, you have your own iä iä monster right now
[22:08:18 CEST] <atomnuker> I am hyping up for codecpar
[22:08:40 CEST] <JEEB> codecpar is mai waifu
[22:09:27 CEST] <durandal_1707> codecpar is cosmetics, sorry
[22:10:20 CEST] <JEEB> durandal_1707: cosmetics that found quite a few WTFs inside the libraries as far as I can tell
[22:10:22 CEST] <Daemon404> it really isnt
[22:10:37 CEST] <Daemon404> fate passes, as expected
[22:10:42 CEST] <Daemon404> nevcairiel, thundbirds are ago?
[22:10:43 CEST] <Daemon404> a go*
[22:11:54 CEST] <durandal_1707> but we want to unite all libs, not to split them properly
[22:12:09 CEST] <Daemon404> "we" = you and nicholas
[22:12:23 CEST] <durandal_1707> Lol
[22:20:38 CEST] <JEEB> durandal_1707: also people are already uniting them anyways if they really want to. just look at those tutorials creating libffmpeg.so|a!
[22:21:21 CEST] <wm4> even merging all libs would be better than the current situation
[22:21:32 CEST] <nevcairiel> Daemon404: fine with me
[22:22:47 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:9200514ad871: lavf: replace AVStream.codec with AVStream.codecpar
[22:22:48 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:6f69f7a8bf6a: Merge commit '9200514ad8717c63f82101dc394f4378854325bf'
[22:23:00 CEST] Action: Daemon404 ducks for cover
[22:23:23 CEST] <wm4> the evil has infected ffmpeg!
[22:25:22 CEST] <Daemon404> harr ahrr funny
[22:25:46 CEST] <JEEB> wohoo!
[22:26:30 CEST] <durandal_1707> src_movie and vf_subtitles are not ported?
[22:27:06 CEST] <Daemon404> only lavf has at the moment, otehr bits get ported in further merges
[22:27:08 CEST] <Daemon404> or by you
[22:27:18 CEST] <Daemon404> the lavf part was by far the hard part
[22:28:48 CEST] <atomnuker> 362 files changed, 6555 insertions(+), 6079 deletions(-)
[22:29:08 CEST] <Daemon404> ... and the next commit to merge is a no-op.
[22:30:46 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:5b9cdf8cba11: avconv: switch opening decoders and encoders
[22:30:47 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:6372c9dc9972: Merge commit '5b9cdf8cba114c41239bf0f9f5e0ccb6977d1c8d'
[22:31:29 CEST] <Daemon404> durandal_1707, 1138eb5509d3db7f6d565cb45f137a786d22beb9
[22:31:37 CEST] <Daemon404> a few merges away, converts vsrc_movie
[22:31:44 CEST] <Daemon404> theirs is probably different than ours though
[22:32:04 CEST] <Daemon404> but im not going to merge more today.
[22:32:48 CEST] <Daemon404> wm4, nevcairiel btw we want to no-op the avconv change to codecpar right? so we can do it ourselves.
[22:32:59 CEST] <nevcairiel> didnt you just do that :D
[22:33:04 CEST] <Daemon404> no
[22:33:12 CEST] <Daemon404> that was a different commit that was actually a no-op
[22:33:24 CEST] <Daemon404> i explained in the merge commit msg
[22:34:05 CEST] <Daemon404> nevcairiel, same for avplay right?
[22:34:24 CEST] <nevcairiel> probably
[22:36:11 CEST] <nevcairiel> merging changes in either of those is rather painful since git has is sues with the rename
[22:36:24 CEST] <Daemon404> you can force git to pick up the rename manually
[22:37:33 CEST] <Daemon404> regardless i think it is better to do it manually
[22:37:44 CEST] <Daemon404> with guidance from the original commit where necessary
[22:38:07 CEST] <wm4> indeed probably better
[22:38:39 CEST] <nevcairiel> both also diverged quite a bit
[22:50:10 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:15e84ed3f141: avconv: convert to codecpar
[22:50:11 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:0705f5960c9d: avplay: do not use AVStream.codec for decoding
[22:50:12 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:c23152a90371: avplay: convert do codecpar
[22:50:13 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:bbf5ef9dac94: Merge commit '15e84ed3f141c586e8cb78ed58365cf5a511108a'
[22:50:14 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:bc91bc1d8b2b: Merge commit '0705f5960c9d272cef1309c090000865b991c9c7'
[22:50:15 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:972df59f4f4d: Merge commit 'c23152a90371bfe971b063781ef4e7d9d5ef9d70'
[22:50:34 CEST] <Daemon404> interestingly, ffplay already was converted not to use st->codec.
[22:50:35 CEST] <Daemon404> in 2013.
[22:50:50 CEST] <wm4> eh
[22:50:59 CEST] <nevcairiel> half the work!
[22:51:17 CEST] <Daemon404> wm4, for decodingh
[22:51:25 CEST] <jamrial> ffplay also has a maintainer, unlike ffserver
[22:51:31 CEST] <Daemon404> yea
[22:54:13 CEST] <Daemon404> ok all the no-ops are done
[22:54:22 CEST] <Daemon404> yoru regularily scheduled merging will resume tomorrow.
[22:59:58 CEST] <Daemon404> jamrial, i sent an email to ffplay's maintainer to see if he wants to work on it, or not
[23:00:12 CEST] <nevcairiel> ffplay should be relatively simple i would think
[23:00:23 CEST] <Daemon404> he already did the hard work
[23:00:30 CEST] <Daemon404> by converting it to use a generic decoder
[23:00:41 CEST] <Daemon404> the hard part for me is testing since there are no unit tests
[23:00:47 CEST] <Daemon404> and SDL is a PITA
[23:00:47 CEST] <Daemon404> :P
[23:00:59 CEST] <nevcairiel> SDL parts shouldnt need touching
[23:01:12 CEST] <Daemon404> no i mean installing it on windows and trying there
[23:01:15 CEST] <nevcairiel> oh
[23:01:15 CEST] <atomnuker> wasn't there an SDL2 patch on the ML?
[23:01:17 CEST] <Daemon404> i usually do my ffmpeg dev work over ssh
[23:01:19 CEST] <Daemon404> on linux
[23:01:45 CEST] <Daemon404> michaelni, i CC'd you on the mail
[23:32:38 CEST] <cone-277> ffmpeg 03James Almer 07master:5501f58e5278: fate: fix sample dependencies for fate-{a,v}filter tests
[00:00:00 CEST] --- Mon Apr 11 2016
1
0
[01:23:44 CEST] <ethe> Is there a flag for ./configure to disable fixed math stuff only?
[01:25:09 CEST] <JEEB> --disable-decoder=aacdec_fixed
[01:25:17 CEST] <JEEB> since that was the one you were having an issue with
[01:25:29 CEST] <JEEB> unless it pops up differently in the configure output
[01:25:35 CEST] <JEEB> in which case I got the decoder name incorrect :P
[01:25:47 CEST] <ethe> hmm, I thought it would be an issue with all the fixed encoders, but actually I think the other ones were fine
[01:26:53 CEST] <ethe> JEEB yeah it's an encoder
[01:27:26 CEST] <ethe> thanks anyways
[01:28:40 CEST] <ethe> well, apparently now it's a decoder .-.
[01:29:44 CEST] <JEEB> I saw CC libavcodec/aacdec_fixed.o
[01:29:49 CEST] <JEEB> in your output :P
[01:30:56 CEST] <JEEB> and yeah, there is just one aac encoder in FFmpeg afaik :)
[01:30:59 CEST] <ethe> yeah... --disable-decoder=aac_fixed was the flag which worked in the end
[01:31:36 CEST] <JEEB> http://fatebeta.ffmpeg.org/ there's a couple of aarch64 machines in FATE nowadays
[01:32:13 CEST] <JEEB> some iOS devices, a qemu instance at least
[01:35:16 CEST] <ethe> my suspicions were correct, ac3dec_fixed failed as well, so it looks like it's all of the fixed decoders which are not working
[01:35:55 CEST] <ethe> although I think those are the only two fixed decoders
[04:00:04 CEST] <drwho7817> I need help recording desktop audio from headset with built in microphone. Can someone help point me in the right direction?
[04:00:42 CEST] <drwho7817> This is my .asoundrc # .asoundrc pcm.!default { type plug slave.pcm hw:1 } defaults.ctl.card 1 defaults.pcm.card 1
[04:01:57 CEST] <drwho7817> What I am really trying to do is stream. I get the stream to work and it picks up my microphone but not my desktop sound. I followed this guide https://trac.ffmpeg.org/wiki/EncodingForStreamingSites
[04:02:33 CEST] <drwho7817> I use Streaming your desktop Without scaling the output and get video to stream picks up mic but no desktop sound.
[04:03:58 CEST] <c_14> https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplication
[04:04:34 CEST] <drwho7817> c_14: I have tried this but I must be doing something wrong since it does not pick up audio.
[04:05:07 CEST] <drwho7817> I make sure to load module first copied that script then edited my sound card.
[04:05:09 CEST] <c_14> Well, the part of your asoundrc that you pasted definitely doesn't capture desktop audio
[04:05:31 CEST] <c_14> What's your ffmpeg command?
[04:06:33 CEST] <drwho7817> ffmpeg -f alsa -ac 2 -ar 44100 -i hw:1 out.wav
[04:06:48 CEST] <drwho7817> ffmpeg -f alsa -ac 2 -ar 44100 -i hw:Loopback,0,0 out.wav
[04:06:56 CEST] <drwho7817> I have tried both
[04:07:52 CEST] <c_14> The first one will record your microphone, the second one won't do anything because you never modified your asoundrc
[04:08:53 CEST] <drwho7817> I changed my asoundrc per the guide you gave me https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplication now where the card <Your Output Device Name>, I edited to say card 1 per my arecord -l output
[04:10:52 CEST] <c_14> If you modified your asoundrc like in the guide you have to do -i hw:Loopback,1,0
[04:11:25 CEST] <drwho7817> ffmpeg -f alsa -ac 2 -ar 44100 -i hw:Loopback,1,0 out.wav <--- this command right?
[04:11:37 CEST] <c_14> yes
[04:11:40 CEST] <drwho7817> I just adjusted my asound.
[04:11:44 CEST] <drwho7817> asoundrc*
[04:12:05 CEST] <drwho7817> I am getting this error now [alsa @ 0x23a5480] cannot open audio device hw:Loopback,1,0 (Invalid argument) hw:Loopback,1,0: Input/output error
[04:12:24 CEST] <drwho7817> I already ran alsactl restore
[04:12:28 CEST] <drwho7817> Should I have to reboot?
[04:12:57 CEST] <c_14> no
[04:13:29 CEST] <c_14> your asoundrc has pcm.!default { type plug slave.pcm "hw:Loopback,0,0" } right?
[04:13:58 CEST] <drwho7817> No it only has that long script that mentions the loopback
[04:14:06 CEST] <drwho7817> Should I add that command if so where?
[04:14:32 CEST] <c_14> That's not a command, that's a line in your .asoundrc
[04:14:41 CEST] <c_14> Can you upload your current .asoundrc to a pastebin service?
[04:15:35 CEST] <drwho7817> 1 sec please
[04:16:45 CEST] <drwho7817> http://pastebin.com/7sqUiTaz
[04:17:44 CEST] <c_14> Ok, delete line 2
[04:17:58 CEST] <c_14> Then do ffmpeg -f alsa -ac 2 -ar 44100 -i loopout out.wav
[04:19:13 CEST] <drwho7817> testing now
[04:19:52 CEST] <drwho7817> no sound
[04:20:52 CEST] <drwho7817> This is my arecord -l output http://pastebin.com/cSY7cdj8
[04:22:27 CEST] <c_14> are you running an application that produces sound?
[04:22:53 CEST] <c_14> Can you hear anything on the output pcm? (card 1 in your case)
[04:22:56 CEST] <drwho7817> sure I test youtube or music stream on vlc
[04:23:05 CEST] <drwho7817> Yeah I can
[04:23:52 CEST] <c_14> Does arecord -D loopout -t wav -c 2 -f cd out.wav work?
[04:24:59 CEST] <drwho7817> I had pulseaudio install just removed it in case it was a conflict
[04:26:09 CEST] <drwho7817> I run your command and get no error but nothing happens either
[04:27:44 CEST] <drwho7817> I think my sound card does not have stereo mix capabilities does this matter or is this what the loopback is for?
[04:27:57 CEST] <eftm> some opencv files compiled during installation for their python library include <ffmpeg/avformat.h>, and *as they are now* these headers files all actually reside under /usr/lib/<avlibraryname>/<avlibraryfiles>. how would i collect them all under the ffmpeg label if they have files that are named the same (like version.h)? or how else would i fix t
[04:27:57 CEST] <eftm> he library organization so they can be recognized by the <ffmpeg/[[avlibraryname.h]]> format? my initial thought was to make the ffmpeg folder and provide symlinks to all of them, but they appear to also need whatever other files belong in each of their current folders
[04:31:39 CEST] <c_14> drwho7817: shouldn't matter afaik, the installed pulse might be it though, it might have left behind some configs, maybe check /usr/share/alsa ?
[04:31:47 CEST] <c_14> eftm: sed the opencv files
[04:33:01 CEST] <drwho7817> c_14: shouldnt the loopin also be set to pcm.loopin { type plug slave.pcm "hw:Loopback,1,0" as my pcm.loopout? and my card 1 in that script?
[04:33:45 CEST] <gcl5cp> i have had problem applying png watermark (overlay) pre-processed by imagemagick, raise a libav core dump error.
[04:34:17 CEST] <gcl5cp> but using gimp to save the alpha png file works well.
[04:34:28 CEST] <drwho7817> c_14: in other words is my asoundrc correct? http://pastebin.com/Sm9xVdPy
[04:34:57 CEST] <drwho7817> or should i leave it default and only edit my card 1 to reflect my sound card being my headset
[04:35:19 CEST] <c_14> drwho7817: no, the slave pcms for loopin and loopout have to use different subdevices
[04:35:37 CEST] <drwho7817> okay I will change it back i am getting an error now anyway
[04:35:49 CEST] <c_14> gcl5cp: what version are you getting the error with?
[04:36:28 CEST] <gcl5cp> the gimp's file weight 2.25KB, and the imagemagick's file 471B
[04:37:33 CEST] <drwho7817> c_14: should i uninstall alsa remove scripts reboot and start fresh?
[04:37:46 CEST] <gcl5cp> ffmpeg version 2.8.1-2~trusty Copyright (c) 2000-2015
[04:38:41 CEST] <c_14> gcl5cp: if you can reproduce with a build from git, open a bug report on trac
[04:39:20 CEST] <c_14> drwho7817: you could do that, what error are you getting though?
[04:39:41 CEST] <drwho7817> im using the git build ffmpeg version git-2016-03-15-7725210 Copyright (c) 2000-2016 the FFmpeg developers
[04:40:03 CEST] <drwho7817> [alsa @ 0x15c3480] cannot open audio device loopout (Device or resource busy) loopout: Input/output error
[04:40:12 CEST] <gcl5cp> ok c_14
[04:40:45 CEST] <drwho7817> when i run ffmpeg -f alsa -ac 2 -ar 44100 -i loopout out.wav
[04:41:49 CEST] <c_14> drwho7817: hmm, strange. do you still have the arecord running or anything else which might be trying to access that device. Maybe an output program from when you had loopin and loopout with the same subdevice?
[04:42:28 CEST] <drwho7817> ah yeah i see arecord running let me kill process
[04:43:15 CEST] <drwho7817> good now
[04:44:07 CEST] <drwho7817> still no audio
[04:44:21 CEST] <drwho7817> Maybe I need wav codecs installed?
[04:44:37 CEST] <c_14> no
[04:45:03 CEST] <c_14> All you should need is a kernel built with alsa, alsa-lib, alsa-utils and maybe alsa-plugins but I'm not sure about the last one
[04:45:46 CEST] <drwho7817> should I recompile ffmpeg from guide? maybe i did something wrong
[04:46:04 CEST] <drwho7817> how can i check to see if kernel has those headers compiled?
[04:48:04 CEST] <c_14> If you can listen to audio your kernel is most probably built with alsa (unless it uses OSS, which would be unusual)
[04:48:13 CEST] <c_14> If arecord can't pick it up, it's probably not ffmpeg
[04:48:55 CEST] <drwho7817> yep I can hear audio from internet stream, local music file and youtube via browser
[04:49:55 CEST] Action: c_14 just copied the .asoundrc to his .asoundrc and it works fine here
[04:51:00 CEST] <drwho7817> hmm should i check my bios?
[04:51:05 CEST] <drwho7817> could it be a setting there?
[04:51:36 CEST] <c_14> very unlikely
[04:51:38 CEST] <c_14> hmm
[04:51:50 CEST] <c_14> Do you have more than one sound card? Something like usb headphones + speakers or something?
[04:52:02 CEST] <drwho7817> then its got to be my headset or soundcard
[04:52:12 CEST] <drwho7817> i have a usbheadset
[04:52:17 CEST] <drwho7817> let me connect it and try that
[04:53:01 CEST] <c_14> What I want to try is setting the "loopin" slave of the multi pcm to the other sound card / usb headset and checking to make sure that sound plays on both
[04:53:10 CEST] <c_14> To make sure that the route is actually doing its job
[04:54:15 CEST] <drwho7817> okay i connected my usb headset
[04:55:35 CEST] <drwho7817> slave.pcm "hw:Loopback,3,0"
[04:55:45 CEST] <drwho7817> arecord -l says my usb headset is card 3
[04:56:34 CEST] <c_14> then it should just be hw:3
[04:56:39 CEST] <drwho7817> i am not getting any audio now out of my usb headset
[04:57:21 CEST] <c_14> are you sure you uninstalled pulse?
[04:58:08 CEST] <drwho7817> this is my new pastebin asoundrc http://pastebin.com/FCN5jAdV
[04:58:19 CEST] <drwho7817> yes i ran apt-get purge pulseaudio pavucontrol
[04:58:58 CEST] <drwho7817> it looks like pulseutils is still installed'
[04:59:37 CEST] <c_14> can you just switch the slave.pcm for pcm.!default to "output" ?
[05:00:32 CEST] <c_14> and then see if you get audio on the usb headphones
[05:01:35 CEST] <drwho7817> pcm.output { <------>type hw <------> slave.pcm hw:3 like this?
[05:02:03 CEST] <c_14> line 28 in the config you pasted, just change the part in quotes to output
[05:04:00 CEST] <drwho7817> done
[05:04:12 CEST] <c_14> then try playing something and seeing if the output goes to your usb headphones
[05:05:32 CEST] <drwho7817> nah
[05:05:36 CEST] <drwho7817> i may have to reboot
[05:05:46 CEST] <drwho7817> its not acting right since i switched headphones
[05:05:50 CEST] <drwho7817> or log out
[05:06:15 CEST] <drwho7817> Hardware is initialized using a generic method No state is present for card Headset
[05:08:15 CEST] <drwho7817> be right back
[05:21:59 CEST] <drwho7817> c_14: my pastebin with new usb headset http://pastebin.com/uUk4yVMA
[05:22:14 CEST] <drwho7817> i just rebooted and not getting any sound
[05:22:38 CEST] <c_14> When playing audio normally?
[05:22:43 CEST] <drwho7817> yep
[05:23:08 CEST] <c_14> Did you check /usr/share/alsa ?
[05:24:07 CEST] <c_14> especially alsa.conf.d
[05:24:50 CEST] <drwho7817> what should i look for?
[05:24:52 CEST] <drwho7817> i have not yet
[05:25:15 CEST] <c_14> anything mentioning pulse
[05:25:27 CEST] <drwho7817> oh
[05:25:31 CEST] <drwho7817> i found pulse stuff
[05:25:33 CEST] <drwho7817> :s
[05:25:45 CEST] <drwho7817> 50-pul50-pulseaudio.conf
[05:25:54 CEST] <drwho7817> 99-pulseaudio-default.conf.example
[05:26:23 CEST] <drwho7817> removing now
[05:28:37 CEST] <drwho7817> still no audio logging off be right back
[05:33:35 CEST] <drwho7817_> sound works again i got it to work from a script online http://pastebin.com/GqBVpXrV
[05:33:45 CEST] <drwho7817_> it wont work with the ffmpeg script :/
[05:33:55 CEST] <drwho7817_> im using the usb headset
[05:35:17 CEST] <c_14> for some reason the route pcm just doesn't seem to want to work for you
[05:36:54 CEST] <drwho7817_> hmm it could be my kernel setup
[05:37:16 CEST] <drwho7817_> maybe ill reinstall debian and build from scratch
[05:37:27 CEST] <drwho7817_> ill try that and update here if i get it working
[05:37:35 CEST] <drwho7817_> i really appreciate you helping me look
[05:50:07 CEST] <c_14> np
[13:39:04 CEST] <brad987> Some help with audio conversion?
[13:39:17 CEST] <brad987> (new here)
[13:41:09 CEST] <brad987> I have a video with audio recorded only to the left channel. I need to convert to stereo. Tried -map_channel 0.1.0 and it worked but think it sounds a bit spacey
[13:42:07 CEST] <brad987> Tried amerge but the way I'm doing it the left channel ends up louder - I think because it's getting added twice: once from the input file and second from the amerge filter
[13:42:18 CEST] <brad987> ffmpeg -i trimmed.avi -vn -af "amovie=trimmed.avi [l] ; [l] [l] amerge" amerge4a.avi
[13:42:59 CEST] <brad987> Can I modify this last command to exclude the base audio from the input file?
[14:28:29 CEST] <brad987> meh actually the map_channel seems ok
[15:40:16 CEST] <volar> /join #
[17:28:20 CEST] <fling> Could not open libavcodec encoder for saving images
[17:28:44 CEST] <fling> How to fix? ^ Do I need to enable png somehow?
[17:29:38 CEST] <JEEB> that's why you generally start off with a build that doesn't have things specifically disabled
[17:29:48 CEST] <JEEB> you make sure your code works with such a build
[17:29:57 CEST] <JEEB> then you start optimizing the build for features and size :P
[17:34:03 CEST] <fling> rebuilt ffmpeg and mpv and the error gone
[17:36:58 CEST] Action: JEEB finally got mpv on android kind of nicely going
[17:37:07 CEST] <JEEB> (except for the OSC which only gets half rendered)
[17:39:43 CEST] <fling> The problem was a broken gentoo ebuild probably
[17:40:05 CEST] <fling> As encode flag on mpv does not change the behavior of this&
[20:27:15 CEST] <Mavrik> JEEB, how do you render? OGL?
[20:27:26 CEST] <JEEB> yeah
[20:27:34 CEST] <Mavrik> Bah sorry, forgot to check timestamps on messages
[20:27:47 CEST] <JEEB> it was fun kind of understanding the android gl view workflow
[20:28:15 CEST] <Mavrik> *sigh*
[20:28:18 CEST] <JEEB> (I basically threw stuff at the walls and checked what was sticking)
[20:28:22 CEST] <Mavrik> For certain meanings of the word :D
[20:28:51 CEST] <JEEB> (my WIP branch for making the context stuff work was/is "garbage_day")
[20:29:08 CEST] <JEEB> but yeah, now I get the OSC working, too https://github.com/jeeb/mpv-android/releases/tag/mpv-android-2016-04-10v2
[20:29:24 CEST] <JEEB> (I broke it while making the stuff in general time right)
[20:29:38 CEST] <JEEB> I must say it was much simpler to get libmpv built :P
[20:32:41 CEST] <Mavrik> Yeah, if it helps I had to do that stuff for an app and made a demo: https://github.com/izacus/AndroidOpenGLVideoDemo :)
[20:32:45 CEST] <Mavrik> If you want shaders and whatnot.
[20:32:49 CEST] <Mavrik> (Uses Andorid codecs tho=
[20:33:03 CEST] <JEEB> I'm leaving most of the work to libmpv
[20:33:08 CEST] <JEEB> which is how it should be
[20:33:29 CEST] <JEEB> I just have to stick the cables into the right inputs and outputs
[20:33:35 CEST] <JEEB> between android and libmpv
[20:33:40 CEST] <Mavrik> yep
[20:33:48 CEST] <Mavrik> SW decoding only though :)
[20:33:50 CEST] <JEEB> nah
[20:33:52 CEST] <JEEB> mediacodec just fine
[20:34:08 CEST] <JEEB> this was the thing I tested mateo's thing with before it got merged
[20:34:49 CEST] <Mavrik> Ahh.
[20:34:55 CEST] <Mavrik> So the MediaCodec stuff was merged?
[20:34:58 CEST] <JEEB> yes
[20:35:26 CEST] <Mavrik> Neat. Need to test device compat to see if I can use it somewhere else :)
[20:35:49 CEST] <JEEB> compatibility itself for the mediacodec thing should be >=4.2
[20:36:19 CEST] <Mavrik> Yeah, but that doesn't guarantee it's not broken or funny sadly :/
[20:36:24 CEST] <JEEB> sure
[20:36:27 CEST] <Mavrik> I've had quite a bit of fun on 4.2 on some devices
[20:36:39 CEST] <Mavrik> Either they had strange pix fmts or plainly just didn't work.
[20:36:41 CEST] <JEEB> but that would be not limited to the libavcodec mediacodec implementation
[20:36:44 CEST] <Mavrik> It got better in 4.4+ though.
[20:36:51 CEST] <Mavrik> Yeah, it doesn't work anywhere then :)
[20:37:18 CEST] <JEEB> in my case the first thing you notice between devices is the way those things fall back
[20:37:43 CEST] <Mavrik> As long as they fall back instead of failing horribly with segfault it's great
[20:37:48 CEST] <JEEB> aka "I feed you 10bit AVC and let's see how badly you are able to let me fall back onto sw dec"
[20:38:04 CEST] <JEEB> my oneplus one is pretty straightforward and works
[20:38:13 CEST] <JEEB> then I think some nexus device just stuck there for 30s
[20:38:19 CEST] <JEEB> others can be even worse :)
[20:38:42 CEST] <JEEB> which is why I think most apps have a profile/level check before feeding to hwdec
[20:39:25 CEST] <Mavrik> <3 MediaTek!
[20:39:27 CEST] <Mavrik> <3 AllWinner
[20:39:35 CEST] <JEEB> yup
[20:39:38 CEST] <Mavrik> "My Hofer Medion tab doesn't work!"
[20:46:57 CEST] <mateo`> JEEB, Mavrik: I've send the mediacodec hwaccel part to the ml to render the output buffers to a surface (in case you didn't notice)
[20:52:02 CEST] <JEEB> yeah, I did notice it :)
[20:52:11 CEST] <JEEB> haven't gotten to writing code for it yet
[20:53:57 CEST] <mateo`> I also have some code to manipulate Surface+SurfaceTexture but i'm not sure I will submit it for upstreaming as it depends on a java class bundled with the application (wich is mandatory, as you have to implement an interface to received SurfaceTexture callbacks)
[20:57:55 CEST] <mateo`> (I think I will send the patch anyway)
[21:49:40 CEST] <Guest69441> Hiiiiiii all
[21:49:58 CEST] <Guest69441> Could you please guide me
[21:50:34 CEST] <Guest69441> i wish to encode a video by ffmpeg
[21:51:05 CEST] <Guest69441> i like that the result be a coded audio and a coded video
[21:51:14 CEST] <Guest69441> is it possible?
[21:52:00 CEST] <Guest69441> suppose my original file is yuv
[21:53:06 CEST] <Guest69441> i mean that i have one file (yuv) and i like two have to encoded (one for video and one for audio)
[21:55:47 CEST] <furq> Guest69441: -i src.yuv -an -c:v foo video.mkv -vn -c:a bar audio.mkv
[21:56:55 CEST] <Guest69441> Oh thanksssss
[22:02:23 CEST] <JEEB> ugh
[22:02:35 CEST] <JEEB> Mavrik: people are trying to remove libfaac wrapper
[22:02:49 CEST] <JEEB> and they're being blocked by "BUT CONSIDER THE USER CHOICE!!!!!!"
[22:02:51 CEST] <Mavrik> Hmm, does anyone still use that? :)
[22:03:02 CEST] <Mavrik> Sometimes the users are morons :P
[22:03:09 CEST] <JEEB> supposedly because faac is 60x real time
[22:03:18 CEST] <JEEB> while aac/fdk-aac are ~30x real time
[22:03:47 CEST] <Mavrik> Hrmf.
[22:03:56 CEST] <JEEB> but yeah, ended up posting in that mailing list thread
[22:03:58 CEST] <Mavrik> Trying to think of an esoteric case where that matters.
[22:04:13 CEST] <JEEB> "running mencoder or ffmpeg on your phone" is the only thing that was brought up
[22:04:17 CEST] <JEEB> as in, cli
[22:04:19 CEST] <JEEB> :V
[22:04:24 CEST] <JEEB> "better battery life"
[22:04:37 CEST] <JEEB> like, I've seen quite a few users here throughout the years
[22:04:59 CEST] <JEEB> and the only reason people have been using faac is due to them reading an old tutorial from before fdk-aac was a thing
[22:05:06 CEST] Action: JEEB sighs
[22:29:19 CEST] <tp_> or they use a package manager to install ffmpeg
[23:39:33 CEST] <kepstin> people who used a package manager to install it used to get vo-aacenc :/
[00:00:00 CEST] --- Mon Apr 11 2016
1
0