Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- 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
August 2015
- 1 participants
- 62 discussions
[03:07:13 CEST] <atomnuker> turns out that ff_lpc_init() does not reserve a big enough buffer to calculate autoc coefficients of over 750 samples
[03:08:21 CEST] <atomnuker> (when the blocksize specified on init is 1024)
[04:35:04 CEST] <cone-912> ffmpeg 03Michael Niedermayer 07master:4bd99f715de3: avcodec/snowenc: Support setting the iterative dia size separately
[10:36:19 CEST] <cone-042> ffmpeg 03Paul B Mahol 07master:7516aa9a4afc: avfilter/vf_vectorscope: implement envelope support
[10:36:19 CEST] <cone-042> ffmpeg 03Paul B Mahol 07master:a902bebdab75: doc/filters: mention all short names for vectorscope options
[12:15:33 CEST] <cone-042> ffmpeg 03Michael Niedermayer 07master:845fb3d4a5f4: avcodec/options: Make dummy_v?_encoder static
[13:26:37 CEST] <cone-042> ffmpeg 03Michael Niedermayer 07master:ab800add7b85: avdevice/libdc1394: Make dc1394_frame_format and dc1394_frame_rate, static
[13:26:38 CEST] <cone-042> ffmpeg 03Michael Niedermayer 07master:fb42e7751634: swresample/swresample-test: Make layouts static const
[14:33:38 CEST] <Daemon404> i gotta say, i think ffmpeg should probably blend as prores normally does.
[14:33:41 CEST] <Daemon404> by default
[14:33:52 CEST] <Daemon404> mind you i lack context of the previous battles.
[14:34:51 CEST] <Daemon404> but i do know we get random complaints about it at work
[14:45:01 CEST] <wm4> holy shit, 23 comments
[14:45:14 CEST] <wm4> oh mine was 22th
[15:15:32 CEST] <Daemon404> wm4, youre fightign a losing battle
[15:15:36 CEST] <Daemon404> you know how "special" carl is
[15:15:47 CEST] <Daemon404> once he has decided it should be closed, it doesnt matter if it really should be
[15:24:07 CEST] <wm4> I know, but there must be a way
[15:24:20 CEST] <Daemon404> no not really
[15:24:40 CEST] <Daemon404> ive never seen it happen
[15:25:06 CEST] <Daemon404> lmao
[15:25:08 CEST] <Daemon404> that last reply
[15:25:09 CEST] <Daemon404> gold.
[15:25:20 CEST] <wm4> yes that's pretty good
[15:26:17 CEST] <wm4> ok posted too... another 10 seconds of my life wasted
[15:27:13 CEST] <kierank> shall I ban carl temporarily
[15:28:31 CEST] <Daemon404> wm4, for comparison: there was one bug where ~4-5 otehr devs said carl was in the wrong, it didnt hel[
[15:28:34 CEST] <wm4> if you can do that and if he closes it again why not
[15:28:34 CEST] <Daemon404> help*
[15:28:51 CEST] <Daemon404> in the end, michaelni mailed him, but nothing changed.
[15:48:08 CEST] <cone-042> ffmpeg 03Paul B Mahol 07master:dead1964ea8c: avfilter/vf_vectorscope: make color mode more useful
[15:57:57 CEST] <durandal_170> Daemon404: which bug?
[16:01:19 CEST] <ubitux> 4746
[16:01:29 CEST] <Daemon404> i think durandal_170 was askign about the one i reference
[16:01:30 CEST] <ubitux> ah, another one, my bad
[16:01:33 CEST] <Daemon404> which was quite a while back
[16:01:37 CEST] <Daemon404> (i dont remember which0
[16:01:57 CEST] <ubitux> hey, does anyone knows a community dedicated to adobe reversing? :P
[16:14:38 CEST] <kierank> ubitux: adobe what?
[16:14:42 CEST] <cone-042> ffmpeg 03Sven Dueking 07master:67e87f8050cb: avcodec/qsv : Added look ahead rate control mode
[16:14:48 CEST] <ubitux> kierank: typically photoshop
[16:19:16 CEST] <Daemon404> wut
[16:23:40 CEST] <durandal_170> ubitux: ida
[16:23:52 CEST] <ubitux> yeah that's not exactly a community
[16:24:20 CEST] <Daemon404> thats a weridly specific thing to have a community about
[16:24:43 CEST] <ubitux> well, there are many niche reverse communities
[16:25:30 CEST] <Daemon404> i havent seen one for a specific vendor
[16:29:05 CEST] <ubitux> you have them for games typically
[16:33:58 CEST] <Daemon404> games are special
[16:34:02 CEST] <Daemon404> they have devoted fanbases
[16:39:42 CEST] <ubitux> and no fan of photoshop?
[16:39:44 CEST] <ubitux> :s
[16:40:47 CEST] <Daemon404> i dont think you quite understand.
[16:41:16 CEST] <Daemon404> nobody has nostalgic memories of photoshop, to the same extent of $love_game
[16:41:31 CEST] <Daemon404> loved*
[16:41:52 CEST] <Daemon404> nor would they need to RE to keep it alive
[16:42:00 CEST] <ubitux> :(
[16:45:58 CEST] <durandal_170> ubitux: what does this black slider do?
[16:46:05 CEST] <ubitux> i don't know :(
[16:46:29 CEST] <ubitux> it's the K parameter of the the CMYK settings
[16:46:46 CEST] <ubitux> i'm able to have a working mixture of CMY and a standalone K
[16:47:02 CEST] <ubitux> but i can't figure out how to make both of them work at the same time
[16:48:17 CEST] <durandal_170> so you have results but need function?
[16:48:44 CEST] <ubitux> yeah, kind of
[16:49:23 CEST] <ubitux> it's a pain to make pages of data result
[16:49:43 CEST] <ubitux> notably bc i couldn't find a way to keep the color grab window open while doing other shit
[16:50:11 CEST] <Daemon404> what exactly are you trying to do
[16:50:26 CEST] <ubitux> understand the K (black) slider in selective color
[16:50:50 CEST] <ubitux> see http://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177224.html
[16:51:00 CEST] <ubitux> ^F FIXME
[16:53:16 CEST] <iive> ubitux: k stands for blacK
[16:53:32 CEST] <ubitux> yeah right i figure that out so far :p
[16:55:11 CEST] <iive> what is to figure out about it?
[16:55:56 CEST] <Daemon404> [15:46] <@ubitux> i'm able to have a working mixture of CMY and a standalone K <-- ?
[16:56:00 CEST] <Daemon404> you dont 'mix' cmy
[16:56:15 CEST] <ubitux> i mean user setting of C, M and Y at the same time
[16:56:21 CEST] <ubitux> that works well so far
[16:56:33 CEST] <ubitux> and the K slider standalone without changing C, M or Y
[16:56:46 CEST] <ubitux> but not CMY + K
[16:56:46 CEST] <iive> cmyk is palette that is based on colors used for printing. you can go without black, but you'd have to use excessive quantities of the other colors
[16:57:00 CEST] <iive> ubitux: it's like RGB+Gray
[16:57:33 CEST] <ubitux> except adding K to either the CMY or the final RGB adjustement doesn't seem to be in the same PS scale
[16:58:02 CEST] <Daemon404> ubitux, there is no definitive way to handle this afaict
[16:58:07 CEST] <Daemon404> unless your goal is 'do what ps does' only?
[16:58:27 CEST] <Daemon404> (also, above: carl being his usuall idiotic self)
[16:58:48 CEST] <ubitux> yes i want to do what ps does exactly
[16:59:03 CEST] <ubitux> notably because i support the PS preset files
[16:59:08 CEST] <Daemon404> i see
[16:59:21 CEST] <Daemon404> as an aside, handling cmyk in ffmpeg seems of little value
[16:59:26 CEST] <Daemon404> in terms of filtering
[16:59:36 CEST] <Daemon404> it's a thing used for print
[16:59:58 CEST] <Daemon404> (andt he fact that people distribute e.g. cmyk jpegs on the web is just people being silly)
[17:00:03 CEST] <iive> film is not printed, is it?
[17:01:01 CEST] <ubitux> Daemon404: the filter is useful to apply a color transformation to a certain range of colors
[17:01:38 CEST] <Daemon404> iive, i can se it now... halftone'd film
[17:01:40 CEST] <Daemon404> glorious
[17:01:41 CEST] <Daemon404> see*
[17:02:00 CEST] <Daemon404> ubitux, how is it useful though
[17:02:06 CEST] <Daemon404> isnt such a filter generally used to prepare prints
[17:02:30 CEST] <ubitux> "the blue of the sky is too powerful, let's make it a bit more dull"
[17:02:39 CEST] <ubitux> "the red of the sun doesn't radiates enough, let's boost it a bit"
[17:02:41 CEST] <ubitux> etc
[17:02:54 CEST] <Daemon404> wouldnt one generally use HSV then
[17:02:57 CEST] <Daemon404> and not CMYK
[17:02:59 CEST] <Daemon404> to adjust
[17:03:16 CEST] <ubitux> CMYK is just the user settings, not the target
[17:03:26 CEST] <Daemon404> i know
[17:03:30 CEST] <Daemon404> thats what im saying.
[17:03:43 CEST] <Daemon404> you'd generally fiddle with H, S, and V, no?
[17:03:53 CEST] <ubitux> it doesn't really matter if for the user it's expressed as CMYK or HSV or whatever
[17:04:00 CEST] <ubitux> i just stick with PS layout
[17:04:17 CEST] <ubitux> it will allow ppl to setup there filter on one frame in PS
[17:04:20 CEST] <ubitux> export the preset
[17:04:22 CEST] <ubitux> and apply to the video
[17:04:28 CEST] <ubitux> just like curves filter
[17:04:49 CEST] <Daemon404> im saying adjusting C, M, Y, and K only makes sense from a user perspective if its intended for print
[17:04:57 CEST] <Daemon404> (someone feel free to correct me)
[17:05:01 CEST] <ubitux> http://xolexo.deviantart.com/art/Selective-Color-Presets-for-Photoshop-3456…
[17:05:03 CEST] <Daemon404> im saying you have a XY problem.
[17:05:09 CEST] <ubitux> you have some examples of presets here typically
[17:05:34 CEST] <ubitux> well, CMYK is understandable from a user perspective as well
[17:05:38 CEST] <ubitux> it's pretty fine as an interface
[17:05:42 CEST] <Daemon404> clearly not
[17:05:44 CEST] <Daemon404> as you failed
[17:05:45 CEST] <Daemon404> ;)
[17:05:56 CEST] <ubitux> yeah well, the devil is in the details for K
[17:06:29 CEST] <ubitux> but saying "i'll increase yellow, reduce cyan, and make red areas a little darker" is prefectly understandable from a user perspective
[17:06:42 CEST] <Daemon404> and K?
[17:07:14 CEST] <Daemon404> anyway
[17:07:16 CEST] <Daemon404> aside from that
[17:07:34 CEST] <Daemon404> i was going to suggest looking in gimp, but i guess gimp is too crappy to have such a thing
[17:07:38 CEST] <Daemon404> maybe krita
[17:07:49 CEST] <ubitux> yeah i didn't find any tool implementing it
[17:08:52 CEST] <Daemon404> wm4, youve just assured that carl will now close all your bugs as soon as you open them.
[17:09:00 CEST] <JEEB> :D
[17:09:14 CEST] <Daemon404> thats why i stopped using trac fwiw
[17:10:10 CEST] <ubitux> so much drama
[17:10:35 CEST] <wm4> trollol
[17:14:31 CEST] <wm4> so what's this actually about
[17:14:41 CEST] <wm4> that a "slow" libswscale option is not on by default?
[17:14:48 CEST] <wm4> so the classic "slow but wrong is better"?
[17:14:55 CEST] <wm4> err
[17:15:00 CEST] <wm4> "fast but wrong"
[17:18:27 CEST] <wm4> lol
[17:18:58 CEST] <wm4> should start a git revert war
[17:19:04 CEST] Action: wm4 goes back to doing nothing
[17:19:14 CEST] <Daemon404> carl vs the world
[17:19:16 CEST] <Daemon404> as per usual
[17:19:18 CEST] <Daemon404> mvoe along folks
[17:28:32 CEST] <Daemon404> i feel bad for the bug reporter.
[17:34:47 CEST] <wm4> ok I sent a patch
[18:04:29 CEST] <cone-042> ffmpeg 03Ganesh Ajjanagadde 07master:0169c4dc818b: avfilter/vf_separatefields: use the name 's' for the pointer to the private context
[18:24:34 CEST] <ubitux> Daemon404: you mean koda?
[18:24:52 CEST] <Daemon404> is that who it is?
[18:24:56 CEST] <ubitux> yes
[18:25:04 CEST] <Daemon404> 50 bucks says carl is being vindictive cunt then
[18:25:14 CEST] <Daemon404> grudge shit
[18:26:19 CEST] <JEEB> lol
[18:26:47 CEST] <Daemon404> i am sadly not joking
[18:36:43 CEST] <durandal_170> what about koda?
[18:54:13 CEST] <kierank> if he closes it again i think it should be ban time
[18:56:09 CEST] <Compn> carl is the top bug trac dev
[18:56:22 CEST] <Compn> banning him would be shooting the project in its face
[18:56:29 CEST] <Daemon404> bullshit
[18:56:29 CEST] <kierank> temporary ban
[18:56:32 CEST] <Daemon404> "dev"
[18:56:48 CEST] <Daemon404> if you mean curator, then maybe.
[18:57:11 CEST] <Compn> carl has posted patches that fix bugs and those patches have been reviewed and committed
[18:57:25 CEST] <Daemon404> those are rarely fixes
[18:57:27 CEST] <Compn> this is a fact, but feel free to be angry at him for closing some bugs
[18:57:30 CEST] <Daemon404> theyre one line changes that hack shit in
[18:57:35 CEST] <Daemon404> and break stuff half the time
[18:57:56 CEST] <kierank> Compn: he's repeatedly closing the bug
[18:58:05 CEST] <Compn> just leave it closed and bookmark it then
[18:58:06 CEST] <kierank> when numerous devs are telling him not to
[18:58:11 CEST] <Daemon404> Compn, thats not a solution
[18:58:14 CEST] <Compn> the status of the bug does not matter in the grand scheme of reality
[18:58:17 CEST] <Daemon404> thats letting the petualant child have his way
[18:58:19 CEST] <Daemon404> to keep the peace
[18:58:19 CEST] <Compn> yes, it is the best solution
[18:58:20 CEST] <wm4> lol
[18:58:34 CEST] <Daemon404> in fact, a number of us here do nto submti bugs to trac
[18:58:36 CEST] <Daemon404> because of carl
[18:58:39 CEST] <Compn> i know
[18:58:43 CEST] <Daemon404> "solution" my ass.
[18:58:45 CEST] <kierank> that's a disgusting attitude
[18:58:48 CEST] <Daemon404> yes it is
[18:59:00 CEST] <wm4> you can bet users aren't fond of this treatment either
[18:59:02 CEST] <Compn> why not post bugs to libav tracker then
[18:59:08 CEST] <kierank> this project has the maturity of a 2 year old
[18:59:27 CEST] <Daemon404> Compn, "but libav is dead" is not a valid reason to endorse shitty behavior
[18:59:42 CEST] <Daemon404> thats like saying "cmon let me cut you! over at libav they'd shoot you, so we're fine"
[19:00:09 CEST] <Compn> what
[19:00:21 CEST] <Compn> i was just suggesting to use their tracker for bugs for people who dont like carl
[19:00:25 CEST] <Compn> since carl does not have power there :P
[19:00:33 CEST] <Daemon404> Compn, libav bugtracker is akin to throwing bugs in a hole
[19:00:37 CEST] <Daemon404> it's a no-op.
[19:00:53 CEST] <Timothy_Gu> <+kierank> if he closes it again i think it should be ban time <-- +1, at least temporarily
[19:00:57 CEST] <kierank> what a state of affairs this project is in when you are happy to accept antisocial behaviour
[19:01:11 CEST] <Daemon404> kierank, there's a term for it. it's called the status quo.
[19:01:14 CEST] <Daemon404> you may have heard of it.
[19:01:14 CEST] <Compn> kierank : no offense, but i see anti-social behavior from many devs in this project.
[19:01:35 CEST] <kierank> right, so many wrongs make a right
[19:01:41 CEST] <kierank> superb logic
[19:01:48 CEST] <Compn> no
[19:01:54 CEST] <Compn> i'm just trying to keep the project together
[19:02:02 CEST] <Compn> you start banning people and they start dissapearing
[19:02:19 CEST] <kierank> or they change their ways and act like adults
[19:02:25 CEST] <Daemon404> you have to have SOME way to enforce reaosnable beahvior
[19:02:29 CEST] <kierank> if they cant do that then perhaps they should bugger off
[19:02:36 CEST] <kierank> vlc had problems in this area and they were dealt with
[19:02:55 CEST] <Timothy_Gu> also another example& michael
[19:04:05 CEST] <Daemon404> it's possible michael, aside from needing time off, has resigned because he doesnt want to deal with the childish antics of teh community at large.
[19:04:21 CEST] <Daemon404> (i do not speak for anyone. just speculation.)
[19:04:42 CEST] <iive> It's easier to see the straw in someone else than the beam in oneself
[19:14:47 CEST] <durandal_170> carl wrote caf muxer, so its not only patches...
[19:17:56 CEST] <Daemon404> 0
[19:23:48 CEST] <durandal_170> what 0?
[19:23:54 CEST] <Daemon404> was an accident
[19:36:29 CEST] <durandal_170> ubitux: could you plot data you have?
[19:52:36 CEST] <ubitux> durandal_170: most of the K related stuff is on a white board, i probably need to complete them and write them down in a formal way
[19:52:52 CEST] <ubitux> it's hard to guess what kind of data will be relevant though
[20:13:56 CEST] <kierank> Timothy_Gu: temporary ban carl?
[20:16:40 CEST] <BBB> cehoyos must understand that his opinions cannot possibly taken for law just by fact of it being him alone?
[20:16:53 CEST] <BBB> I mean, if he was right, that would be one thing, but this...
[20:17:10 CEST] <BBB> funny though
[20:17:25 CEST] <BBB> our community is as unhealthy as it ever was and will ever be
[20:17:26 CEST] <BBB> sad
[20:17:30 CEST] <kierank> I'm happy to ban him but I suspect Compn will complain and say he wasn't consulted
[20:19:49 CEST] <wm4> this reminds me that we don't have a real decision making process in ffmpeg
[20:20:10 CEST] <kierank> no shit
[20:20:13 CEST] <kierank> it was dictatorship before
[20:20:22 CEST] <wm4> (still is)
[20:20:31 CEST] <wm4> this group of certain core devs is like a wall
[20:20:32 CEST] <BtbN> File a bug about carl not behaving.
[20:20:34 CEST] <wm4> can't overrule them
[20:20:45 CEST] <wm4> BtbN: edit war: the ticket?
[20:21:12 CEST] <wm4> (and by "core devs" I don't mean in terms of contributions)
[20:21:31 CEST] <BtbN> I have seen that actualy happening a few times, in various projects. It's not neccesarily ment as a joke.
[20:23:21 CEST] <wm4> well, at least we don't have commit revert wars
[20:27:05 CEST] <Timothy_Gu> kierank: yes
[20:27:33 CEST] <kierank> I am nervous about doing this
[20:28:17 CEST] <wm4> in his logic, he rejected the patch, which justified closing the issue
[20:28:28 CEST] <wm4> makes perfect sense huh
[20:33:31 CEST] <ubitux> kierank: beware of getting classified as one of the traitors etc
[20:34:05 CEST] <kierank> I don't particularly give a shit whether I am a traitor/thief/liar/swine etc
[20:54:47 CEST] <iive> I think the default behaviour should be blending with checkboard texture
[20:55:04 CEST] <iive> this way it would be both black and white.
[20:55:21 CEST] <iive> also, so does photoshop :)
[21:03:18 CEST] <wm4> still better than just discarding alpha
[21:10:56 CEST] <iive> then it is decided!
[21:13:36 CEST] <durandal_170> no, i want it in pink
[21:14:41 CEST] <wm4> can the blend color be set?
[21:25:33 CEST] <durandal_170> not yet
[21:40:16 CEST] <iive> durandal_170: checkboard pattern on pink and yellow!
[21:41:56 CEST] <durandal_170> yes there are many possibilities
[21:44:14 CEST] <iive> gold and blue?
[22:34:06 CEST] <Compn> [14:20] <wm4> this group of certain core devs is like a wall
[22:34:10 CEST] <Compn> who is a core dev btw ?
[22:34:35 CEST] <Compn> because i dont include myself as one.
[22:34:51 CEST] <Compn> why you guys listen to me as if i have any say around here is strange...
[22:35:19 CEST] <Compn> but i hope you listen to my advice at least and do not ignore me like some people have before
[23:47:22 CEST] <cone-042> ffmpeg 03Andreas Cadhalpun 07master:e6c20e214efd: avfilter: add missing FF_API_AVFILTERBUFFER guards
[23:47:23 CEST] <cone-042> ffmpeg 03Andreas Cadhalpun 07master:c34363acd21c: mux: warn if the encoders bitexact flag is set, but not the muxers
[23:47:24 CEST] <cone-042> ffmpeg 03Andreas Cadhalpun 07master:c64060d56a04: fate: add -fflags +bitexact to the relevant targets
[00:00:00 CEST] --- Mon Aug 31 2015
1
0
[01:08:06 CEST] <fred1807> Could anyone kindle help find what is the difference between two small video files? I tried ffprobe... there is nothing more I can do to understand why 1 video freezes my raspberry pi and other dont
[03:22:29 CEST] <Abbott> Is there a support channel for ID3v2?
[04:57:57 CEST] <Evidlo> Are there any voice compression codecs for ffmpeg?
[05:37:00 CEST] <chungy> Like speex or opus?
[08:38:05 CEST] <Fyr> how to find out what version of ffmpeg is installed?
[08:38:22 CEST] <Fyr> it responds on --version in a weird way.
[08:39:40 CEST] <pzich> it's just -version
[08:40:16 CEST] <Fyr> =)
[08:40:23 CEST] <Fyr> why --help, but -version?
[08:40:49 CEST] <pzich> looks like -help also works
[08:41:07 CEST] <Fyr> for 2.7.2 - it doesn't.
[08:41:09 CEST] <pzich> -h, -?, -help, --help [arg]
[08:54:47 CEST] <chungy> yeah ffmpeg uses X-style args
[09:03:27 CEST] <frenda> What is the 420p in this: -pix_fmt yuv420p?
[09:03:56 CEST] <frenda> ffmpeg -video_size 1920x1080 -framerate 50 -f x11grab -i :0,0 -c:v libx265 -pix_fmt yuv420p output.mp4
[09:04:04 CEST] <pzich> https://en.wikipedia.org/wiki/YUV#Y.27UV420p_.28and_Y.27V12_or_YV12.29_to_R…
[09:06:45 CEST] <frenda> Ah
[09:10:57 CEST] <frenda> What's wrong w/ this command:
[09:11:06 CEST] <frenda> ffmpeg -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0+0,0 -c:v libx265 -pix_fmt yuv420p output.mp4
[09:11:48 CEST] <frenda> 1. I does not stoped by pressing `q` key!
[09:11:59 CEST] <frenda> 2. Th captured video is damaged!
[10:44:49 CEST] <Mavrik> x265 for realtime capture?
[10:44:51 CEST] <Mavrik> Why.
[11:13:10 CEST] <Polochon_street> Hi! Does someone know with what flags I need to compile ffmpeg in order to debug programs with -fsanitize=address
[11:30:57 CEST] <DHE> you probably want --extra-flags=-fsanitize=address
[11:31:04 CEST] <DHE> (I usually use valgrind though)
[11:33:07 CEST] <DHE> *extra-cflags
[11:33:29 CEST] <DHE> do experiment a bit. compiler flags can have all sorts of side-effects
[12:09:51 CEST] <TikityTik> I'm having issues like, [h264 @ 0x7f5f7c0086c0] Missing reference picture
[12:09:56 CEST] <TikityTik> [h264 @ 0x7f5f7c0086c0] decode_slice_header error
[12:10:04 CEST] <TikityTik> from a video I encoded with libx264
[17:08:44 CEST] <Polochon_street> Hm, I'm trying to debug memory leaks, and I installed ffmpeg with debug symbols (finally!) but I all have is this: http://sprunge.us/PdCE
[17:09:00 CEST] <Polochon_street> is there a mean to see where the av_malloc() took place?
[17:09:34 CEST] <JEEB> is that valgrind?
[17:09:44 CEST] <JEEB> IIRC it should also output the stack trace
[17:10:02 CEST] <JEEB> if it's not valgrind, then I deeply recommend it
[17:10:16 CEST] <Polochon_street> it's the -fsanitize=address option of gcc
[17:10:25 CEST] <JEEB> ok, so probably less useful
[17:10:34 CEST] <JEEB> try running your code under valgrind next time
[17:10:37 CEST] <Polochon_street> what options should I pass to valgrind in order to have all the stack trace?
[17:10:47 CEST] <c_14> valgrind --leak-check=full
[17:10:56 CEST] <Polochon_street> thanks
[17:10:58 CEST] <JEEB> yeah, that was it
[17:11:30 CEST] <JEEB> I used to do valgrind for things that have children etc so I used to use
[17:11:31 CEST] <JEEB> --leak-check=full --track-origins=yes --trace-children=yes
[17:11:58 CEST] <Polochon_street> okay, thanks. Let's see!
[17:13:24 CEST] <Polochon_street> ah-ha!
[17:13:54 CEST] <Polochon_street> http://pastebin.archlinux.fr/1489347
[17:13:55 CEST] <Polochon_street> found it!
[17:17:35 CEST] <JEEB> Polochon_street: now wonder how fun it is to find that stuff /without/ the ability to use valgrind
[17:20:03 CEST] <Polochon_street> (I don't want to ._.)
[17:20:53 CEST] <JEEB> I do a lot of development on windows, no valgrind there
[17:20:55 CEST] <Polochon_street> okay, so after I avformat_open_input'd an avformatctx, apart from freeing it with avformat_close_input(), should I do something else?
[17:21:18 CEST] <Polochon_street> heh, that's why I really don't want to work on windows
[17:21:47 CEST] <JEEB> yeah, that's why most of my stuff can compile on lunix and windows
[17:22:01 CEST] <JEEB> so I can test it out on both
[17:22:07 CEST] <JEEB> (and use valgrind on the lunix side)
[17:22:36 CEST] <JEEB> Polochon_street: https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbn…
[17:22:43 CEST] <JEEB> looks like I also called avformat_free_context()
[17:25:37 CEST] <Polochon_street> hm, that didn't solve my problem, but it can't hurt either. Thanks!
[17:33:01 CEST] <Polochon_street> okay, I'm almost there, it seems that freeing an avformat is not so simple
[17:33:02 CEST] <Polochon_street> http://pastebin.archlinux.fr/1489348
[17:33:27 CEST] <Polochon_street> I'm calling avformat_close_input(&pformatCtx) and avformat_free_context(pFormatCtx)
[18:18:46 CEST] <Polochon_street> JEEB: You may want to edit your code, I checked, and avformat_close_input() already performs an avformat_free_context() (cf https://www.ffmpeg.org/doxygen/2.5/libavformat_2utils_8c_source.html)
[18:19:44 CEST] <JEEB> that might or might not have been true before :) but sure
[18:19:50 CEST] <JEEB> that code I haven't touched since ~2013 or so
[18:20:13 CEST] <JEEB> just to see how hard it would be to poke the Windows explorer thumbnails system
[18:30:21 CEST] <Polochon_street> yeah you're right, sorry. Now I'm trying to understand why, despite an av_freep(&s->internal) inside the avformat_free_context(), I'm still having this leak
[22:10:18 CEST] <AlexanderSh> Hello! I'm decoding udp multicast stream use ffmpeg. Source: Hardware encoder, 1080i, GOP structure is IBBP, I frame each 6 frames. But I have the lag about 30 frames. How to reduce latency?
[23:40:47 CEST] <sarkyniin> hey
[23:41:09 CEST] <sarkyniin> how do I replace an mkv file's subtitle track?
[23:55:15 CEST] <KarlFranz> Use mkvtools for that.
[00:00:00 CEST] --- Mon Aug 31 2015
1
0
[04:09:04 CEST] <Zerowalker> is it possible to tell ffmpeg to copy instead of encoding data in code?
[04:09:27 CEST] <Zerowalker> like the "-acodec copy" thingy
[04:12:12 CEST] <cone-812> ffmpeg 03Philip Langdale 07master:91f1115a0e02: avcodec/vc1dec: Re-order init to avoid initting hwaccel too early
[04:15:14 CEST] <michaelni> Anssi, carl says in https://trac.ffmpeg.org/ticket/4797 that its a regression since da7759b3579de3e98deb1ac58e642b861280ba54, or maybe EXT-X-BYTERANGE dont work with .mp4
[06:23:29 CEST] <andrewrk> I switched from libav to ffmpeg for my music player, and it broke gapless playback. I'm not complaining - I'm looking for troubleshooting clues. Any suggestions?
[06:23:45 CEST] <andrewrk> I pipe all the decoded audio through a ffmpeg filter graph
[06:24:02 CEST] <andrewrk> I rebuild the filter graph in the seam between tracks
[06:25:45 CEST] <andrewrk> I suppose I could try an older version of ffmpeg and see if it was a recent commit that changed things
[06:26:17 CEST] <andrewrk> Also I suppose I should join #ffmpeg instead
[07:33:07 CEST] <durandal_1707> andrewrk: commands, code?
[07:34:10 CEST] <andrewrk> durandal_1707, well, I could link you to the existing codebase if you wanted to have a look. Or I could work on a small self contained example to demonstrate the problem
[07:35:12 CEST] <andrewrk> durandal_1707, here's a link: https://github.com/andrewrk/libgroove/blob/master/src/playlist.cpp#L668
[07:35:40 CEST] <andrewrk> I don't expect you to read all this, but hey I'll throw it out there.
[07:53:24 CEST] <durandal_1707> andrewrk: and how it behaves, that makes it incorrect?
[07:56:23 CEST] <andrewrk> durandal_1707, when line 711 happens, we seek to the beginning of a song which is supposed to have gapless playback, but instead, there is a small glitch heard
[07:58:25 CEST] <andrewrk> it is calling av_seek_frame and avcodec_flush_buffers on the second file's AVFormatContext
[07:58:40 CEST] <andrewrk> I wonder, would that cause a glitch sound?
[08:06:00 CEST] <andrewrk> ok yes it is that, I have narrowed it down
[08:07:22 CEST] <andrewrk> durandal_1707, ok so the problem is that I'm seeking to 0 and that is causing a glitch in the playback
[08:27:48 CEST] <durandal_1707> are you using abuffersink filter?
[08:30:14 CEST] <andrewrk> durandal_1707, yes
[08:40:44 CEST] <andrewrk> I wonder if it is an ogg vorbis specific problem
[08:42:35 CEST] <andrewrk> durandal_1707, aha, I do not experience the problem with flac
[08:42:40 CEST] <andrewrk> it must be an ogg thing
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:f55cc579115e: aac: move the TNS tables from aacdectab to the shared aactab
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:20962b567b4d: lpc: create a simplified Levinson-Durbin LPC handling float samples
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:949a4892fa1d: aacenc: change FF_PROFILE_UNKNOWN to AAC-Main if prediction is enabled
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:44ddee945a2e: aacenc_pred: rework the way prediction is done
[08:48:44 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:1cd5daee2060: aac: remove now-unused redundant array
[08:48:45 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:f20b67173ca6: aacenc_tns: rework the way coefficients are calculated
[08:48:45 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:f04d86c16a5d: aacenc: remove TNS from the todo list
[08:48:46 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:fe12ba6f3012: fate: reenable TNS test
[08:48:46 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:4ff897a5364f: fate: add a test for encoding AAC-Main prediction
[09:08:17 CEST] <wm4> andrewrk: seek to start time
[09:09:57 CEST] <andrewrk> wm4, how?
[09:11:13 CEST] <andrewrk> wm4, currently I am passing 0 for timestamp and 0 for flags in av_seek_frame
[09:11:22 CEST] <andrewrk> is there a different way to seek to start time?
[09:11:49 CEST] <wm4> yes by using the start time
[09:12:10 CEST] <andrewrk> how does one obtain the start time?
[09:13:11 CEST] <wm4> (also, no idea if this is really the cause)
[09:13:39 CEST] <andrewrk> ah, AVStream::start_time
[09:16:49 CEST] <andrewrk> wm4, just checked, start_time is reported as 0 which is what I was already passing
[09:16:59 CEST] <andrewrk> thanks for the suggestion though
[09:19:42 CEST] <andrewrk> so, if I remove the seek-to-0, gapless playback works perfectly
[09:19:58 CEST] <andrewrk> but I need that seek in there because sometimes I want to play a file again without closing and re-opening it
[09:20:45 CEST] <andrewrk> I think this is enough info to open an issue
[09:20:57 CEST] <andrewrk> and if more evidence is needed I can produce a test case
[09:21:08 CEST] <nevcairiel> if we're talking about mp3 files exclusively, you can just use a byte seek to position 0 and see if that helps
[09:21:19 CEST] <andrewrk> this is ogg vorbis
[09:21:24 CEST] <andrewrk> I don't expect gapless playback to work with mp3
[09:21:24 CEST] <nevcairiel> oh well
[09:22:11 CEST] <andrewrk> this works in libav btw, maybe I could look at a code diff
[09:25:05 CEST] <wm4> it should work in ffmpeg too
[09:25:37 CEST] <wm4> I fixed it to make mp3 gapless actually work
[09:26:05 CEST] <wm4> there are fate tests too
[09:26:14 CEST] <andrewrk> oh wow, let me try a couple songs from my library...
[09:26:31 CEST] <nevcairiel> seeking will likely still break something
[09:26:39 CEST] <andrewrk> even seeking to 0?
[09:26:49 CEST] <andrewrk> It seems like that should be a special case that should always work
[09:30:41 CEST] <nevcairiel> just track if you actually n eed to seek and avoid it if not, it'll save you a bunch of problems in general
[09:32:38 CEST] <andrewrk> hmm good point
[09:32:48 CEST] <wm4> I specifically fixed seeking with gapless mp3
[09:35:15 CEST] <andrewrk> wm4, I'm excited, about to try this out
[09:35:35 CEST] Action: andrewrk gets out Another Brick In The Wall, Part 2
[09:38:20 CEST] <andrewrk> wm4, I heard a small skip. but couldn't that be the fault of the ripper?
[09:38:52 CEST] <andrewrk> I thought that mp3 files had to have frames of a certain length, so they ended up getting padding and you just can't have gapless mp3
[09:40:22 CEST] <andrewrk> hmm let me try again without seeking to 0
[09:44:11 CEST] <andrewrk> nevcairiel, so, this is an incomplete solution, because let's say I have tracks 1 and 2 on a playlist. So I open both the files, and play them both and never call av_seek_frame
[09:44:24 CEST] <andrewrk> nevcairiel, then I go back and play them again
[09:44:43 CEST] <andrewrk> now the tracks must be seeked since they were played once, and we lost gapless playback
[09:45:03 CEST] <andrewrk> if I wanted such a workaround I would be forced to close the file and re-open it. but that seems silly
[09:45:09 CEST] <andrewrk> also it introduces race conditions
[09:45:25 CEST] <andrewrk> I think the right thing to do is special case seeking to 0 in ffmpeg codebase
[09:45:28 CEST] <nevcairiel> you could just re-open them, keeping them open permanently seems like a odd situation anyway, if you play a playlist of 5 tracks, do you keep all of them opened, and not close them when advancing to the next one?
[09:46:35 CEST] <andrewrk> nevcairiel, I keep the 5 tracks before the current song in the play queue and 5 tracks after the current song in the play queue open
[09:47:54 CEST] <andrewrk> they're not permanently open, it's just a resource caching problem
[09:48:06 CEST] <andrewrk> I keep them open if they're likely to get played
[09:50:25 CEST] <andrewrk> ok I'm just going to have a look at the ogg code and see if there's an obvious solution
[09:57:49 CEST] <andrewrk> the only difference between ffmpeg and libav is ogg_reset(s) called twice in ogg_read_seek
[10:28:13 CEST] <cone-166> ffmpeg 03Rostislav Pehlivanov 07master:8323d9b8afbc: fate: adjust AAC encoder TNS test fuzziness
[12:09:38 CEST] <ubitux> wm4: 0 length? you mean the duration of an event?
[12:10:04 CEST] <wm4> ubitux: yes
[12:10:07 CEST] <ubitux> unknown as in "next sub will replace previous one"?
[12:10:32 CEST] <wm4> I found lrc uses -1 to signal unknown length (while the API says 0), so I just started using that (because a user complained)
[12:10:45 CEST] <wm4> yes, or as in the last event is shown forever
[12:10:47 CEST] <ubitux> for standalone text sub this is handled with lavf/subtitles, which will deal with the duration itself
[12:10:58 CEST] <ubitux> ah yeah, except the last one
[12:11:27 CEST] <ubitux> i don't think we wrote a given convention
[12:14:52 CEST] <ubitux> yeah so basically, a duration=-1 will be replaced by the appropriate duration in the finalize step for standalone subs
[12:14:59 CEST] <ubitux> except for the last sub which will keep that -1
[12:15:46 CEST] <ubitux> you should get a packet with duration=-1, not 0
[12:16:01 CEST] <ubitux> (which will result in the ASS max time in the decoded form though)
[12:16:06 CEST] <ubitux> (iirc)
[12:19:10 CEST] <wm4> yes but the API docs say unknown lengths use 0
[12:19:16 CEST] <wm4> so I suggest we change the docs
[12:19:22 CEST] <ubitux> oups, yeah
[12:19:23 CEST] <wm4> and then fix whatever cases there are
[12:19:36 CEST] <ubitux> it might be different for bitmap subs
[12:19:43 CEST] <ubitux> which were there in the first place
[12:20:26 CEST] <wm4> yes htey need to be fixed
[12:20:37 CEST] <wm4> in fact I'd like if av_init_packet inits duration to -1
[12:20:53 CEST] <ubitux> it's a bit tricky with stuff like dvb subs iirc
[12:21:55 CEST] <ubitux> wm4: in which case duration=0 is meaningful?
[12:22:09 CEST] <ubitux> invisible sub?
[12:22:26 CEST] <wm4> yes
[12:22:27 CEST] <ubitux> (because of time scale differences ?)
[12:22:33 CEST] <wm4> no
[12:22:53 CEST] <wm4> ASS subs definitely have events with duration of 0 that need to be invisible
[12:23:38 CEST] <ubitux> question about this: are they supposed to impact the positioning of overlapping subs?
[12:23:58 CEST] <ubitux> question not clear, let me reword
[12:24:31 CEST] <ubitux> when you have a dialogue printed on the screen, and another dialogue appears overlapping with the second one, it goes above
[12:24:49 CEST] <michaelni> atomnuker, fate-aac-tns-encode fails with assertion failure on builds with --assert-level=2
[12:24:57 CEST] <ubitux> but if the first dialogue disappear (or do not actually appear bc of duration=0)
[12:24:58 CEST] <wm4> I have no idea how it's supposed to be handled
[12:25:06 CEST] <ubitux> is the above dialogue going down or stay above?
[12:26:10 CEST] <wm4> libass would probably respect only actually rendered events
[12:27:04 CEST] <ubitux> what would be the purpose of these invisible dialogue?
[12:27:13 CEST] <ubitux> if they have 0 impact on the output?
[12:27:37 CEST] <wm4> so you're suggesting the demuxer should discard them?
[12:27:47 CEST] <ubitux> no it's a real question
[12:27:50 CEST] <ubitux> i'm just wondering
[12:28:07 CEST] <wm4> I'd say they still need to be representable
[12:39:29 CEST] <michaelni> atomnuker, fate-aac-tns-encode also shows out of array reads under valgrind
[12:42:24 CEST] <michaelni> atomnuker, http://pastebin.com/wWVU727t
[12:51:03 CEST] <kurosu__> "levinsion" ? levinson you mean
[13:32:15 CEST] <saste> all gsoc projects were successfull, good
[13:32:40 CEST] <kierank> there was one bad iirc
[13:32:45 CEST] <saste> michaelni, what about an IRC meeting before the next VDD?
[13:32:52 CEST] <saste> kierank, yes it failed at midterm
[13:38:05 CEST] <michaelni> saste, sure, pick a day/time thats convenient for most people ...
[13:38:54 CEST] <saste> I could create a doodle, or settle for the next Saturday
[14:29:45 CEST] <y2k> hi! in a dumuxer, I don't know how many frames I have written. how do I add support for chapters in such formats (when the number of frames written is not known). the underlying codec is mp3. is there some neat magic in ffmpeg to do this?
[14:30:43 CEST] <Compn> you talk about demuxers and writing frames
[14:30:48 CEST] <Compn> which is usually a muxer thing...
[14:31:08 CEST] <Compn> what format are you talking about specifically? mkv ordered chapters ?
[14:46:25 CEST] <ubitux> https://pornel.net/deringing/ old?
[14:52:37 CEST] <durandal_1707> ubitux: what are you doing?
[14:55:15 CEST] <cone-442> ffmpeg 03Clément BSsch 07master:b48d8fa3ac38: avfilter: add allrgb
[14:55:44 CEST] <ubitux> durandal_1707: i'm back on selectivecolor, nothing related to the above link
[14:57:12 CEST] <ubitux> we should use allrgb/allyuv for 1:1 color pixel filters
[14:57:22 CEST] <ubitux> in fate
[14:58:50 CEST] <ubitux> michaelni: atomnuker: fate also fails here with:
[14:58:52 CEST] <ubitux> Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:157
[14:59:04 CEST] <ubitux> in aac-tns-encode test
[15:08:00 CEST] <ubitux> fate also fails on on api-seek and asf-repldata with --disable-everything
[15:18:32 CEST] <durandal_1707> release with major bumps should be 3.0
[16:08:37 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:16229fae9c0d: avfilter/vf_vectorscope: add yet another mode
[18:41:24 CEST] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:47b41feb7283: avfilter/af_apad: use the name 's' for the pointer to the private context
[19:02:28 CEST] <atomnuker> ubitux: on it
[19:04:19 CEST] <ubitux> see also the valgrind error from michaelni
[19:06:43 CEST] <jamrial> ubitux: allrgb.png 34.8MB, post "optipng -o7" it becomes 58kb :P
[19:06:57 CEST] <ubitux> jamrial: haha nice
[19:07:00 CEST] <jamrial> much better than allyuv
[19:07:39 CEST] <ubitux> i wonder if it would have been that compressable with a different layout
[19:08:13 CEST] <wm4> jamrial: can you upload that anywhere?
[19:09:07 CEST] <jamrial> wm4: ffmpeg -f lavfi -i allrgb -vframes 1 allrgb.png && optipng -o7 allrgb
[19:10:25 CEST] <jamrial> wm4: but in case you don't have optipng http://i.imgur.com/8aFtnrh.png
[19:13:16 CEST] <jamrial> wm4: you said there may be some obscure avoptions to get better compression with our encoder, but ffmpeg -h encoder=png doesn't show anything
[19:14:04 CEST] <ubitux> jamrial: try -compression_level
[19:14:20 CEST] <ubitux> (generic option)
[19:15:47 CEST] <ubitux> i wonder if the squary layout isn't detected somehow by optipng
[19:17:19 CEST] <jamrial> -compression_level 4 and above are all the same. 3 and below are slightly bigger
[19:17:26 CEST] <Timothy_Gu> jamrial: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/pngenc.c#L1046-L1048
[19:19:06 CEST] <jamrial> webp lossless is still better. 9kb
[19:32:17 CEST] <durandal_1707> what about 256x256x256 frames, this needs less memory
[19:34:34 CEST] <durandal_1707> atomnuker: so you are writting spectrogram, have you considered doing it using lavfi?
[19:43:39 CEST] <atomnuker> I was thinking of using lavc and libfftw3
[19:44:19 CEST] <atomnuker> but it should be easy to modify the current showspectrum to figure out a length in pixels such that it would never wrap
[19:47:14 CEST] <Timothy_Gu> atomnuker: we have our own fft: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avfft.h
[19:48:12 CEST] <atomnuker> yes, I know, just a fan of that library
[19:48:49 CEST] <atomnuker> I'll see what can be done to showspectrum first
[20:01:13 CEST] <wm4> I don't see any point in making a release with all the old API
[20:24:37 CEST] <jamrial> wm4: probably to please distros, since apparently dropping three years old apis is a big deal
[20:24:55 CEST] <durandal_1707> atomnuker: cache frames like showwaves
[20:26:09 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:0818705bf37e: aacenc_tns: fix triggering an assertion with assert-level=2
[20:26:10 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:49854c56c234: aacenc: initialize LPC context with MAX_LPC_ORDER
[20:26:11 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:902ac9ca74d5: aacenc_tns: actually apply TNS filter to the coefficients
[20:26:12 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:e924967fd5ec: aacenc_tns: fix out-of-bounds array access
[20:26:46 CEST] <jamrial> next version will be after the bump, and if some distros can't be bothered to update their ffmpeg-dependent packages they'll at least have a version newer than 2.7 to use
[20:26:55 CEST] <atomnuker> michaelni: valgrind exits without any errors for me
[20:27:47 CEST] <atomnuker> kurosu__: on it
[20:33:03 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:141d80ded779: lpc: rename ff_lpc_calc_levinsion to ff_lpc_calc_levinson
[21:30:19 CEST] <philipl> which nick is Paul? i forget.
[21:32:38 CEST] <wm4> philipl: durandal_1707 ?
[21:33:32 CEST] <durandal_1707> yes
[21:45:09 CEST] <philipl> I got bored and started trying to implement support for the packed yuva444 format that vdpau uses
[21:45:47 CEST] <philipl> i tried copying the ayuv64 swscale code and clipped values to 8 bits but everyhing looks very dark
[21:46:13 CEST] <philipl> i wonder if i messed that up or its a colourspace conversion problem on the vdpau side
[21:52:17 CEST] <durandal_1707> philipl: you need to shift more
[21:53:33 CEST] <philipl> i shifted 23 in place of your 15.
[21:53:38 CEST] <philipl> that seems logical.
[22:04:49 CEST] <durandal_1707> you only do output?
[22:05:22 CEST] <philipl> In this case it's output only. Taking a 444planar source and sending it to vdpau
[22:05:41 CEST] <philipl> I wrote the input path in swscale too but that's trivial by comparison.
[22:07:58 CEST] <philipl> durandal_1707: https://github.com/philipl/FFmpeg/commit/fd4eb7c10c169d9699223391817939b117…
[22:11:16 CEST] <durandal_1707> and if you use format filter it displays correctly?
[22:11:51 CEST] <philipl> I haven't tried. I put it through mpv into vdpau and it shows up very dim, but with the right basic colours.
[22:11:58 CEST] <philipl> Let me try format filter
[22:12:22 CEST] <philipl> I mean, I used the format filter in mpv to trigger conversion from yuv444p to this and then sent that to vdpau
[22:13:31 CEST] <durandal_1707> but try back from it to yuv444p
[22:13:56 CEST] <durandal_1707> assuming input path is correct
[22:14:36 CEST] <durandal_1707> Also look at yuv2422*template
[22:15:02 CEST] <wm4> did you confirm that mpv allocates the 444 packed surface correctly? (lots of messiness here due to interaction with pixdesc)
[22:15:42 CEST] <philipl> wm4: I think so. I see recognisable output on the screen, just very dim.
[22:23:12 CEST] <philipl> whelp. Back and for conversion did not produce anything reasonable.
[22:23:13 CEST] <philipl> *sigh*
[22:24:06 CEST] <philipl> I take that back.
[22:24:14 CEST] <philipl> I got something recognisable but all shades of green.
[22:24:22 CEST] <philipl> Different from what i saw through vdpau playback
[22:43:07 CEST] <Anssi> michaelni: ok thanks, I'll take a look at https://trac.ffmpeg.org/ticket/4797
[23:07:10 CEST] <cone-442> ffmpeg 03Rostislav Pehlivanov 07master:21bfeec27f93: aacenc_tns: do not limit the filter size
[00:00:00 CEST] --- Sun Aug 30 2015
1
0
[01:04:28 CEST] <AlexanderSh> Can anyone help me? I'm trying to read udp multicast stream. I have tried this chain: avformat_open_input->avformat_find_stream_info->avcodec_find_decoder->avcodec_open2->decode_loop, where decode_loop - while(av_read_frame != mystream) -> do(avcodec_decode_video2 until got_picture or no luck). But ffmpeg tell me that ffmpeg illegal short term buffer state detected h264. The stream from hardware decoder 1080i, MPEG4, H.264.HD
[01:05:49 CEST] <AlexanderSh> ffpay is playing the stream without problems.
[01:06:45 CEST] <AlexanderSh> Tried set buffer_size from url - no luck.
[01:19:31 CEST] <AlexanderSh> ff: missing reference picture. default is <number>
[01:25:33 CEST] <DHE> just guessing (i have no API experience) but are you trying too hard to decode what you get once you join? with multicast there's no promise that you start with a keyframe, so you need to tolerate a few codec errors until it finds a GOP start
[01:32:11 CEST] <AlexanderSh> GOP settings (from hardware encoder) IBBP, I frame every 6 frames, GOP is closed. when i'm using ffplay it start decodef normal after 1-2 seconds of errors. But when I use my code errors fall without stop. from console: Missing reference picture is 66055 (9 times) afer Illegal short term buffer state detected (1 time) and then all repeted again. Missing pictures are 66055..66061..66067. Distance between missing pictures always equals to 6. Likes I am
[01:32:11 CEST] <AlexanderSh> not getting I-frame. But ffplay play without triubles.
[01:48:10 CEST] <AlexanderSh> I'm compare the output from av_dump_format from my code and ffplay.
[01:48:15 CEST] <AlexanderSh> ffplay:
[01:48:19 CEST] <AlexanderSh> Stream #0:0[0x1000] Video h264 (High) ([27][0][0][0]/0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25 fps,25 tbr, 90k tbn, 50 tbc
[01:48:23 CEST] <AlexanderSh> my code:
[01:48:28 CEST] <AlexanderSh> Stream #0:0[0x1000] Video h264 ([27][0][0][0]/0x001B), none, 25 fps, 25 tbr, 90k tbn, 180k tbc
[01:48:36 CEST] <AlexanderSh> And i'
[01:49:40 CEST] <AlexanderSh> And I have got another error:could not find codec parameters for stream 0: unspecified size. Consider incresing the value form 'analyzeduration' and 'probesize' options.
[01:51:19 CEST] <AlexanderSh> in my code, ffmpeg doesn't identify stream correctly. No frame format (missing yuv420p and frame size).
[01:56:38 CEST] <AlexanderSh> Set AVFormatContext.max_analyze_duration2 and AVFormatContext.probesize2. Now outputs from av_dump_format are the same.
[01:57:23 CEST] <AlexanderSh> but avcodec_decode_video2 still output mising reference picture. default is ....
[03:40:47 CEST] <AlexanderSh> Solved and got frame. Changed read_packaet/decode loop, and set probe size and analyzeduration larger.
[03:41:46 CEST] <AlexanderSh> how to reduce latency? if I set decoder info directly is latence get smaller?
[06:33:05 CEST] <solrize> i'm trying to upload to icecast from x11grab interface... it worked before but now crashes with av_interleaved_write_frame(): connection reset by peer
[06:33:11 CEST] <solrize> web search finds some useless hits about that
[06:33:13 CEST] <solrize> any idea?
[06:37:45 CEST] <tommd> How do I get an AVFormatContext that represents a particular format? I'm trying to get a context for avfoundation for use in avformat_open_input().
[06:38:22 CEST] <tommd> However, I can't find where in the API I could get an AVFormatContext.
[06:49:51 CEST] <kyleogrg> hello
[06:50:21 CEST] <kyleogrg> forgive the simple question, but i am having trouble knowing the way to search for the solution
[06:50:55 CEST] <kyleogrg> in windows cmd, how can i break up a long command line for ffmpeg? a tutorial suggested using a backslash, but it is not working for me...
[07:21:50 CEST] <solrize> backslash is for linux shell
[10:05:29 CEST] <uvx3> Hi! How can I convert FLAC to lossy WavPack?
[12:08:55 CEST] <_Crash_> I'm about to compile the latest version off ffmpeg from git, and when I've come to ./configure, I'm getting a warning saying "WARNING: Option --enable-decoder=liba52 did not match anything". Any ideas?
[12:12:28 CEST] <_Crash_> Is it necessary to include it in the ./configure?
[12:15:28 CEST] <jookiyaya> what version of h265 does ffmpeg support
[12:19:21 CEST] <Guest65363> While stitching images to video, ffmpeg exits if the filename of the first image has an index greater than 4.
[12:19:35 CEST] <Guest65363> Why does it have this limitation?
[13:45:58 CEST] <Polochon1street> Hi! I'm decoding an audio file, by using a while(av_read_frame()) loop. I have some memory leaks, and someone on the mailing told me to « flush the codec by passing a NULL packet to it »
[13:46:20 CEST] <Polochon1street> Am I doing it right? http://pastebin.archlinux.fr/1484142
[16:41:33 CEST] <utack> Hi. I was wondering if H265 decode speed developed from 2.6 to 2.7 and if there is any chance for it to get faster in the future? (not hoping for miracles here, but my machine runs some low bitrate x265 encoded movies and some with higher bitrate are just a tiny bit too slow with ffmpeg 2.6 in kodi)
[16:51:44 CEST] <c_14> I only found one explicit optimization between 2.6 and 2.7.2, if you can use recent git there's now support for both vdpau and vaapi accelerated hevc decoding if your system supports either of those.
[16:54:28 CEST] <utack> i heard about that, but it definitly can not. mabe i will add a gpu for that later if things do not work on the cpu
[16:54:29 CEST] <utack> thanks
[18:33:55 CEST] <solrize> anyone suggest how to get vp8 bit rate lower? we're having network probs. command i'm using right now is http://lpaste.net/3145526325515649024 INRES=640x480 OUTRES=540x270 FPS=15
[18:34:10 CEST] <solrize> and i think i tried FPS=10
[18:34:16 CEST] <solrize> GOP=5 since we're streaming to browsers
[19:07:21 CEST] <BtbN> a goplength of 5 is terrible, something like 2x or 4x FPS is usualy a good value
[19:20:26 CEST] <solrize> BtbN i'm told i have to use gop < 10 in order to stream to browsers. bigger gop failed pretty badly though it worked in mplayer and vlc.
[19:32:04 CEST] <BtbN> That's basicaly IFrame only mode, you need a realy high bitrate for that to look any good.
[20:43:18 CEST] <tommd> ANsewring my own question: av_input_video_device_next is the magic I was missing. You can construct an AVFormatContext from priitives plus this global list of supported formats.
[22:35:12 CEST] <techtopia> hello, getting an error i have never seen before when encoding
[22:35:23 CEST] <techtopia> codec for video requires global header but does not contain global headers
[22:35:38 CEST] <techtopia> and errors out without starting the encode
[22:37:05 CEST] <Mavrik> :)
[22:37:25 CEST] <techtopia> ok i was doing it remotely via teamviewer
[22:37:37 CEST] <techtopia> getting the source video now so will be able to pb it in a few mins
[22:38:00 CEST] <BtbN> Why would using ffmpeg remotely change anything about pasting the output
[22:39:10 CEST] <techtopia> because im not longer connected to his box to grab the log
[22:39:18 CEST] <techtopia> he is uploading the video so i can have a look locally
[22:39:25 CEST] <techtopia> and when he does then i can get the log :p
[22:41:07 CEST] <fred1807> I need raw h264 videos for my raspberry, I am converting like: ffmpeg -i source.mp4 desti.h264 but I am having problems with timecode... some videos are not played entirely by raspberry video player (hello_video.bin)
[22:42:31 CEST] <techtopia> the mp4 could contain a .h264 track
[22:42:41 CEST] <BtbN> raw h264 bitstream does not carry any timestamps.
[22:42:45 CEST] <techtopia> might be an idea to just try demux it
[22:42:49 CEST] <BtbN> also, you might want to add -c copy
[22:44:49 CEST] <fred1807> this is raspberry native hardware raw h264 player: https://github.com/adafruit/pi_hello_video/blob/master/hello_video/video.c There must be something I am missing because some videos play 100% , while some freeze in the middle. All of them I created with "ffmpeg -i source.mp4 dest.h264" but they came from different sources (vimeo, youtube, cam...)
[22:45:12 CEST] <fred1807> this player only plays .h264 without audio
[22:45:18 CEST] <fred1807> no container
[22:46:51 CEST] <fred1807> could the source of these videos be the cause? Or after the moment I convert with "ffmpeg -i s.mp4 d.h264" they are all the same??
[22:49:18 CEST] <techtopia> the documentation says it will only play the first 15 seconds of a video
[22:49:36 CEST] <techtopia> https://www.raspberrypi.org/documentation/usage/demos/hello-video.md
[22:49:40 CEST] <techtopia> "This will play a 15 second long full HD 1080p video clip with no sound. The intention here is to demonstrate video decode and playback capability. Youll see that the video is very smooth!"
[22:51:19 CEST] <fred1807> actually it plays way more
[22:51:48 CEST] <techtopia> not sure whats up then
[22:51:58 CEST] <techtopia> it does sound like kinda alpha software atm
[22:52:00 CEST] <fred1807> 15 seconds is the lengh of that demo
[22:52:03 CEST] <fred1807> bug bunny
[22:52:25 CEST] <fred1807> ok, my question is about ffmpeg actually
[22:52:32 CEST] <fred1807> and movie encoding in general..
[22:52:44 CEST] <fred1807> are all raw h264 video the same?
[22:52:53 CEST] <techtopia> no
[22:53:13 CEST] <techtopia> they can be diffrent resolutions, diffrent frame rates, and so on
[22:53:23 CEST] <techtopia> you can though encode them all to one standard
[22:53:37 CEST] <fred1807> ok... my stantard for raspberry is 720p
[22:53:41 CEST] <techtopia> like find a video that works, see what resolution the video is, see what frame rate it is
[22:53:48 CEST] <c_14> fred1807: compare the output of ffprobe -show_format -show_streams for a working and a non-working file
[22:53:48 CEST] <techtopia> then encode all future videos to that spec
[22:54:11 CEST] <fred1807> resolution, frame rate, what else counts for h264?
[22:54:29 CEST] <fred1807> is there any timelenght information on file?
[22:56:23 CEST] <fred1807> Hmmm.. Analysing files with mediainfo.. I can see that a always working file has a tag for fram rate
[22:56:26 CEST] <fred1807> frame rate
[22:56:38 CEST] <fred1807> while some of the freezing files dont have this tag at all
[22:56:50 CEST] <fred1807> how can I force frace rate calculation and tag when converting with ffmpeg ??
[22:57:10 CEST] <techtopia> you can add -r whatever, before -i to specify the source inputs frame rate
[22:57:15 CEST] <techtopia> like
[22:57:24 CEST] <techtopia> ffmpeg -r 25 -i blah blah blah
[22:57:58 CEST] <fred1807> btw, this working video frame rate is: Frame rate 118.437 fps isnt that too much?
[22:58:13 CEST] <techtopia> yup heh
[22:58:18 CEST] <Mavrik> unless it's a 120fps camera
[22:58:24 CEST] <Mavrik> it's probably misdetected
[23:06:21 CEST] <fred1807> hmm the same video, with -r 25 (now with frame rate tag) is double the size... (ffmpeg -r 25 -i old.h264 new.h264)
[23:10:49 CEST] <fred1807> Strangely as it may seem, (ffmpeg -r 25 -i old.h264 new.h264) did NOT added a frame rate tag to the new movie
[23:13:50 CEST] <Donald_ET3> Is it possible to get a quality image out of the jpeg2000 or libopenjpeg encoders? My jpeg2000 output has very bad blocking artifacts, while libopenjpeg adds horizontal lines and so much discoloration it might as well be a black and white video.
[23:14:19 CEST] <Donald_ET3> Are there quality control commands for these encoders?
[23:15:33 CEST] <Donald_ET3> Or is this just the state of things at the moment?
[23:15:58 CEST] <techtopia> Mavrik http://pastebin.com/7nXr0dVX
[23:17:08 CEST] <Mavrik> The error seems descriptive enough :)
[23:17:30 CEST] <Donald_ET3> JPEG2000 looks like a very interesting format, but I can't find a way to encode images in the format.
[23:17:46 CEST] <Donald_ET3> With reasonable quality.
[23:19:59 CEST] <fred1807> not black magic will add a frame rate information to some h264 files :/
[23:20:16 CEST] <fred1807> what else can I try?
[23:21:48 CEST] <techtopia> it crashes out after encoding a few frames
[23:22:08 CEST] <techtopia> if i omit the "-acodec copy"
[23:22:22 CEST] <techtopia> it still errors out after the first few frames
[23:24:23 CEST] <techtopia> im not really fussed about the audio just the video
[23:25:51 CEST] <kyleogrg> so in linux, when i have a long ffmpeg command, i can break it up with \. how about windows?
[23:26:18 CEST] <Mavrik> techtopia, same error?
[23:26:56 CEST] <Mavrik> fred1807, h264 raw file cannot carry that information, mux it into a proper container.
[23:27:58 CEST] <fred1807> Mavrik: I have raw h264 files here that mediainfo can show a frame rate tag, and they are exactly the files that plays fines. btw this raspberry tool only plays raw h264 video
[23:28:19 CEST] <fred1807> there is something possible to be done in ffmpeg, or mp4box, that makes all those videos the same
[23:32:57 CEST] <techtopia> mavrik http://pastebin.com/0Zh0gADf
[23:33:00 CEST] <techtopia> not the same error no
[23:33:18 CEST] <techtopia> but the encoded output only plays like the first five frames on repeat
[23:33:22 CEST] <techtopia> it just glitches out
[23:34:14 CEST] <Mavrik> techtopia, hrmf, that's strange, since I don't really see anything wrong in the output or the command
[23:34:20 CEST] <Mavrik> input is playable I guess?
[23:34:49 CEST] <Mavrik> techtopia, btw, you're heavily duplicating frames, is that expected?
[23:36:49 CEST] <techtopia> no
[23:36:54 CEST] <techtopia> frames should be unique
[23:37:13 CEST] <techtopia> input plays back ok
[23:42:11 CEST] <Mavrik> techtopia, since you're first deinterlacing and then forcing fps back to 50
[23:42:20 CEST] <Mavrik> that will duplicate all your deinterlaced frames
[23:48:24 CEST] <techtopia> it bob deinterlacing though
[23:50:07 CEST] <techtopia> yeah the frames are unique at 50fps
[23:50:50 CEST] <eiji> hei :P
[23:54:14 CEST] <techtopia> o/
[00:00:00 CEST] --- Sun Aug 30 2015
1
0
[00:28:53 CEST] <cone-386> ffmpeg 03Zhang Rui 07master:92d378067ee3: ffplay: remove unused include libavutil/colorspace.h
[00:28:54 CEST] <cone-386> ffmpeg 03Michael Niedermayer 07master:e2b19a533dbb: avformat/segment: atomically update list if possible
[01:27:26 CEST] <cone-386> ffmpeg 03rogerdpack 07master:832b4a4a438b: configure: Print out enabled programs
[01:56:32 CEST] <BtbN> philipl, yeah. The comments in the libva headers actualy sound doable. One flag shouldn't matter at all though, as it only affect temporal layering.
[04:16:57 CEST] <cone-386> ffmpeg 03Michael Niedermayer 07master:3322f0d4158f: avcodec/dnxhddata: Fix inconsistent table entry
[04:42:17 CEST] <cone-386> ffmpeg 03Donny Yang 07master:51ca70322296: apng: Support inter-frame compression
[05:58:16 CEST] <rcombs> https://gist.github.com/rcombs/ceb5473baa329ff8153c wat
[05:58:26 CEST] <rcombs> so& the init function locks the roll-your-own-mutex, then loads the .so and initializes that, which... calls the first init function again, which waits forever to take the mutex
[06:04:35 CEST] <cone-386> ffmpeg 03Carl Eugen Hoyos 07master:b009d5b1f73c: configure: Do not let the webm muxer suggest external libraries.
[06:06:34 CEST] <cone-386> ffmpeg 03Thilo Borgmann 07master:2392da164a02: Changelog: Mention the change of the default webm codecs.
[06:37:38 CEST] <rcombs> apparently this happens if you compile mfx_dispatch as a dynamic lib
[07:33:00 CEST] <philipl> rcombs: well, you tried to use mfx, so you're already on the losing side.
[07:34:00 CEST] <rcombs> philipl: in the end, I succeeded!
[07:35:03 CEST] <philipl> well, congratulations. What did you encode? :-)
[07:35:13 CEST] <rcombs> random file I had laying around
[07:35:41 CEST] <rcombs> was mostly just testing to see if I could build it without too much pain
[07:35:48 CEST] <rcombs> and now that I know how, yes, I can
[07:35:54 CEST] <philipl> I think the main challenge there is getting the SDK from intel.
[07:36:31 CEST] <rcombs> that's not too difficult either
[07:36:40 CEST] <rcombs> but again, you need to know where to find it
[07:36:52 CEST] <rcombs> and you need to give them an email address (though it doesn't verify it)
[07:37:20 CEST] <philipl> I haven't succeeded but I also didn't try very hard
[07:37:36 CEST] <rcombs> and then you download like 500MB worth of crap, half of which is open-source stuff that's already on GitHub or elsewhere
[07:38:06 CEST] <rcombs> and open 3 layers deep of .tgz files and navigate an obnoxious dir structure until you finally find the 2 .so's you wanted
[07:38:14 CEST] <rcombs> (really you only need 1 of them)
[07:38:44 CEST] <rcombs> and then you can finally do what you could already have done directly via vaapi if you were a bit more masochistic
[07:39:01 CEST] <philipl> Masochistic enough that no one's written that code and probably never will.
[07:39:12 CEST] <rcombs> I have!
[07:39:23 CEST] <philipl> You wrote vaapi encoding code?
[07:39:30 CEST] <philipl> I'm sorry.
[07:39:43 CEST] <rcombs> I just hacked the sample code into lavc for some testing a while back
[07:40:17 CEST] <philipl> Definitely masochistic.
[07:40:37 CEST] <philipl> Still, I'm glad that someone who doesn't work for Intel has proven this qsv stuff works on linux.
[07:40:48 CEST] <philipl> your sacrifice is appreciated.
[07:41:05 CEST] <rcombs> the libmfx stuff is overall less pain
[07:41:27 CEST] <rcombs> but I think could probably have more things go wrong
[07:41:49 CEST] <rcombs> extra library layer doing weird Intel things, loading proprietary libs&
[07:42:03 CEST] <rcombs> and super awkward from a licensing standpoint
[07:51:24 CEST] <philipl> yeah, makes it all unusable in practice.
[07:51:36 CEST] <philipl> although handbrake somehow got into a position to ship with qsv on windows.
[07:55:09 CEST] <rcombs> my biggest concern is whether or not it's actually GPL-compatible
[08:00:25 CEST] <philipl> The Handbrake folks seem quite careful about that (they won't accept nvenc for sure). Maybe they got some special licencing language from Intel.
[09:56:04 CEST] <wm4> j-b: will it be sufficient if I arrive on Saturday 9 AM at the airport in Paris?
[10:10:33 CEST] <nevcairiel> with airports being how they are, you will be slightly late and miss the first event or something, i would s ay
[11:10:55 CEST] <cone-534> ffmpeg 03Carl Eugen Hoyos 07master:24e0b14c4f8b: Changelog: Clarify that the new asf demuxer is optional.
[11:48:48 CEST] <j-b> wm4: might be a bit short
[11:48:52 CEST] <j-b> wm4: but doable.
[11:58:08 CEST] <wm4> I think I'd prefer this over arriving at 10 pm the day before
[13:06:43 CEST] <cone-534> ffmpeg 03Harshit Mittal 07master:53bf32fa4270: doc/examples/filtering_video: better demo ffmpeg filters; demos chaining the filters
[13:15:51 CEST] <BtbN> philipl, so, what about going for 2.8 now, as vaapi hevc is also in?
[13:17:11 CEST] <wm4> 2.8, as in making a new ffmpeg release?
[13:17:15 CEST] <BtbN> yes
[13:17:32 CEST] <wm4> it should be synchronized with Libav if possible
[13:17:36 CEST] <nevcairiel> isnt the bump from libav planned to be soon
[13:17:56 CEST] <nevcairiel> either we still do it shortly before and then one later in sync with libav, or we just wait until the bump now
[13:18:05 CEST] <BtbN> I don't realy follow libav development. If some major bump is planned there, that'd definitely be a good point for the next release.
[15:32:58 CEST] <wm4> what's happening on VDD on sunday?
[15:33:07 CEST] <wm4> in fact, what's happening on VDD at all?
[15:33:18 CEST] <durandal_170> beer
[15:33:36 CEST] <Daemon404> wm4, vdd is a few talks, then an unconference
[15:33:40 CEST] <Daemon404> hacking rooms, etc
[15:33:52 CEST] <Daemon404> schedule generally updated in realtime on the wiki
[15:33:59 CEST] <j-b> Sat morning is going to be talks
[15:34:01 CEST] <Daemon404> e.g. one year, there was an opus-in-mp4 room
[15:34:04 CEST] <Daemon404> where that was hashed out
[15:34:13 CEST] <j-b> It might be also a bit Sat afternoon
[15:34:37 CEST] <j-b> Sat Afternoon then there is the VLC technical meeting with in // the other technical meetings by projects
[15:34:40 CEST] <j-b> then unconference
[15:34:50 CEST] <wm4> unconference = beer?
[15:34:51 CEST] <j-b> 18h30 is the VideoLAN org meeting, with the elections
[15:34:59 CEST] <j-b> and then whole Sunday is unconference
[15:35:22 CEST] <Daemon404> wm4, unconferenc is like rooms and stuff
[15:35:23 CEST] <Compn> wm4 : no, its more like 'hang out in office and chat'
[15:35:27 CEST] <Daemon404> look at previous years wiki
[15:35:30 CEST] <Daemon404> for examples
[15:36:06 CEST] <Compn> wm4 : some companies use this time to recruit developers into jobs :P
[15:36:06 CEST] <j-b> in theory, people list the topics
[15:36:24 CEST] <j-b> well, if someone needs a job, I know plenty
[15:36:26 CEST] <Compn> company spies at vdd no doubt :P
[15:36:37 CEST] <j-b> not to mention that I'd like to hire everyone of you
[15:36:42 CEST] <j-b> well, except Compn
[15:36:53 CEST] <wm4> use Compn to deal with your enemies?
[15:36:58 CEST] <Compn> i do not work well with others. :P
[15:37:01 CEST] <Daemon404> Compn should be the ideal hitman
[15:37:04 CEST] <Daemon404> he lives in detroit
[15:37:08 CEST] <Daemon404> gun expert
[15:37:09 CEST] <Compn> raycist.
[15:37:14 CEST] Action: Daemon404 runs
[15:37:15 CEST] <durandal_170> when will be next irc meeting?
[15:37:33 CEST] <Compn> i do not like guns, too loud
[15:38:03 CEST] <Daemon404> the loudness bothers you, but not the kill-y stuff?
[15:38:12 CEST] <Compn> durandal_170 : irc meeting for what
[15:38:23 CEST] <wm4> where's that VDD wiki?
[15:39:29 CEST] <Compn> wm4 : https://wiki.videolan.org/VDD14/Sessions/
[15:39:39 CEST] <Daemon404> s/14/XX/ for otehr years
[15:39:57 CEST] <wm4> Daemon404: yeah, but I didn't find it anyway
[15:41:01 CEST] <kierank> Compn: nobody tried to recruit anyone
[15:41:46 CEST] <Compn> i saw youtube talking to and offering jobs to people
[15:42:58 CEST] <Daemon404> that's because youtube has The Google PRoblem
[15:43:06 CEST] <Daemon404> hiring PHDs who cant code for real
[15:43:08 CEST] <Daemon404> or lack common sense
[15:43:18 CEST] <Compn> mencoder jobs :P
[15:43:22 CEST] <Compn> bwahaha
[15:43:32 CEST] <Daemon404> "they dont know the difference between pts and dts" -- actual quote from thierry
[15:43:40 CEST] <wm4> but those PHDs are good in tricky interview puzzles?
[15:43:43 CEST] <kierank> youtube was not hiring
[15:43:51 CEST] <Daemon404> kierank, not now, no
[15:43:51 CEST] <kierank> they were just talking to reimar about the binary loader
[15:43:58 CEST] <kierank> whatever that may or may not do at youtube
[15:44:01 CEST] <Daemon404> however 50 otehr departments of google are
[15:44:10 CEST] <Daemon404> i get regular spam from some tv startup thei acquired
[15:44:13 CEST] <Daemon404> they*
[15:44:15 CEST] <kierank> which one
[15:44:37 CEST] <nevcairiel> Didn't get a Google offer this year yet
[15:44:44 CEST] <Daemon404> their was an artice lately...
[15:44:45 CEST] <Daemon404> cant remember
[15:44:49 CEST] <Daemon404> they open source it recently i think
[15:45:10 CEST] <nevcairiel> SageTV?
[15:45:21 CEST] <Daemon404> yeah that.
[15:46:11 CEST] <nevcairiel> The old leader of that project contacted me once about recruitment, but I dont know for what exactly at google
[15:46:23 CEST] <nevcairiel> Didn't really bother to find out
[16:16:41 CEST] <nevcairiel> So libav pushed their bump, shall I just merge it as is and enjoy flame posts after? =p
[16:20:19 CEST] <wm4> of course
[16:20:45 CEST] <nevcairiel> the only really controversial changes seem to be the pix_fmts, which are truely butt-old
[16:20:50 CEST] <nevcairiel> and the avcodec frame API
[16:21:29 CEST] <nevcairiel> both are trivial replacements, at the very least
[16:21:56 CEST] <aballier> branch 2.8 before if there's anything you to be want widely used since 2.7
[16:22:16 CEST] <aballier> want to be*
[16:23:06 CEST] <nevcairiel> The major FFmpeg users will adapt anyway, all the flaming is about all those things noone even knows about it exists
[16:23:58 CEST] <aballier> distributions dont update until all those things noone knows are good or killed :)
[16:24:01 CEST] <aballier> s/dont/cant/
[16:24:17 CEST] <aballier> so this usually gives a few months delay
[16:24:25 CEST] <aballier> at least
[16:25:06 CEST] <aballier> (and i excpect major ffmpeg users to have already adapted to be fair)
[16:25:10 CEST] <BtbN> If the merge is easy and doesn't break a lot of API, i'd just go for it.
[16:25:37 CEST] <nevcairiel> it intentionally removes a bunch of old deprecated shit
[16:26:20 CEST] <wm4> also this was discussed to death
[16:29:19 CEST] <aballier> im just pointing facts: what this implies, not discussing whether its good or not (which i'm more in favor of good anyway)
[16:29:54 CEST] <Daemon404> nevcairiel, the pix fmts are also the easiest to fix
[16:29:58 CEST] <Daemon404> literally one line of sed
[16:30:03 CEST] <nevcairiel> <nevcairiel> both are trivial replacements, at the very least
[16:30:09 CEST] <Daemon404> yea.
[16:34:20 CEST] <wm4> Daemon404: still too hard for debian
[16:34:23 CEST] Action: wm4 runs
[16:34:31 CEST] <wm4> actually there's nothing to run from
[16:50:58 CEST] <philipl> BtbN: waiting for the bump seems reasonable. Is this (equivalent to) the 57 bump?
[16:51:13 CEST] <philipl> Have we finished marking everything we wanted for deprecation?
[16:51:24 CEST] <Daemon404> philipl, this stuff has been deprecated for years...
[16:51:44 CEST] <philipl> Of course.
[16:51:59 CEST] <wm4> also that means shit I have missed the window to attempt to deprecate and provide replacements for some pet peeves of mine, like AVPicture
[16:52:19 CEST] <philipl> Ok, I mean two things. 1) Anything like old-vdpau which wasn't properly marked. 2) Is anyone still fighting any of the deprecations?
[16:53:06 CEST] <philipl> wm4: There's always next time :-P
[16:53:26 CEST] <Daemon404> what acpicture stuff even needs replacements besides avpicture_layout?
[16:54:00 CEST] <wm4> AVSubtitle
[16:54:12 CEST] <Daemon404> nah.
[16:54:44 CEST] <nevcairiel> the window for marking things is still open until the first release, imho
[16:55:00 CEST] <Daemon404> indeed
[16:55:25 CEST] <philipl> nevcairiel: So just to make sure I'm in sync, the libav bump is the bump that we were busy preparing for the last few weeks? Not the one after that one right? :-)
[16:55:37 CEST] <nevcairiel> yes
[16:55:45 CEST] <philipl> K. All good then.
[17:00:52 CEST] <cone-534> ffmpeg 03Paul B Mahol 07master:9f2fa95bd8e8: avfilter/vf_histogram: 9 and 10 bit depth support
[17:08:51 CEST] <wm4> a concise bug report
[17:09:12 CEST] <wm4> durandal_170: you should write what it's needed for
[17:10:19 CEST] <durandal_170> for exr and to rule them all
[17:16:55 CEST] <cone-534> ffmpeg 03Philip Langdale 07master:1e50f953fac7: Changelog: Add VDPAU HEVC to the list
[17:36:38 CEST] <wm4> dammit arranging flights is so annoying
[17:37:05 CEST] <Daemon404> trains are an option too
[17:37:17 CEST] <wm4> 2x-3x slower
[17:37:27 CEST] Action: Daemon404 will have flown 65000 miles, and 53 flights at the end of 2015
[17:37:28 CEST] <Daemon404> so.
[17:38:06 CEST] <Daemon404> i assume you'd grab a lufthansa or germanwings flight from $germancity
[17:39:55 CEST] <wm4> yep, and which is 1 hour away from where I live
[17:40:54 CEST] <Daemon404> lufthansa does regional train connections doesnt it
[17:41:27 CEST] <wm4> probably, but doesn't make it faster
[17:41:37 CEST] <wm4> also I'm starting out from Florence for reasons
[17:42:13 CEST] <j-b> take the night train from Florence on Friday night.
[17:42:17 CEST] <j-b> clearly the best option.
[17:43:15 CEST] <Daemon404> im going to get looks from feepk or j-b for my flights
[17:43:22 CEST] <Daemon404> i took a weird routing that was the same price as direct
[17:43:31 CEST] <Daemon404> because miles.
[17:43:35 CEST] <JEEB> lol
[17:44:11 CEST] <Daemon404> adding a intra-europe connection is usually free
[17:44:18 CEST] <Daemon404> or very cheao
[17:44:19 CEST] <Daemon404> cheap
[17:44:53 CEST] <j-b> Daemon404: aren't you coming from UK?
[17:44:56 CEST] <Daemon404> j-b, i am
[17:45:01 CEST] <j-b> Eurostar?
[17:45:08 CEST] <Daemon404> plane was cheaper
[17:45:11 CEST] <Daemon404> euostar is so hit or miss
[17:45:14 CEST] <Daemon404> IME
[17:45:40 CEST] <Daemon404> planes from london to paris (even with connectiosn) are cheao
[17:45:44 CEST] <Daemon404> because they compete with eurostar
[17:45:54 CEST] <Daemon404> same to brussels
[17:46:21 CEST] <kierank> meh
[17:46:22 CEST] <j-b> OK, I won't ask.
[17:46:30 CEST] <j-b> London goes to Disneyland directly :)
[17:46:33 CEST] <Daemon404> lol
[17:46:40 CEST] <kierank> yes but the timings were not good for the disneyland train
[17:46:46 CEST] <kierank> you arrived mid-afternoon
[17:46:47 CEST] <kierank> iirc
[17:46:48 CEST] <Daemon404> even coursmich said my plane routing was insane
[17:46:52 CEST] <Daemon404> that should tell you everything
[17:48:33 CEST] <Daemon404> j-b, well also
[17:48:41 CEST] <Daemon404> last time i was on teh eurostar, i very nearly got in a fistfight
[17:48:43 CEST] <Daemon404> so.
[17:48:45 CEST] <Daemon404> <_<
[17:48:51 CEST] <kierank> why
[17:49:13 CEST] <Daemon404> i told off a guy who was harassing the bartender
[17:49:22 CEST] <Daemon404> one of those pish rich spoiled kids from Chelsea
[17:49:25 CEST] <Daemon404> posh*
[17:49:31 CEST] <Daemon404> got a "do you know who my dad is?"
[17:49:33 CEST] <Daemon404> go from there.
[17:49:40 CEST] <j-b> No, and I don't care.
[17:49:54 CEST] <Daemon404> ofc
[17:49:55 CEST] <Shiz> "unless he's on the train right now, why should i care"
[17:50:37 CEST] <Daemon404> anyway point: im not fleecing videolan for money
[17:50:41 CEST] <Daemon404> im just insane.
[17:51:39 CEST] <kierank> "No, but your mum on the other hand..."
[17:52:15 CEST] <Daemon404> that guy got remove from the car in the end, anyway
[17:52:28 CEST] <Daemon404> bartender called security on him
[17:53:07 CEST] <kierank> should have kicked him off at ashford
[17:53:14 CEST] <kierank> or calais
[17:53:25 CEST] <Daemon404> i dont know what they did after
[17:53:29 CEST] <Daemon404> they very well could have
[18:33:46 CEST] <kierank> i bet that ticket could just be solved by putting the encode in a different thread
[18:33:47 CEST] <kierank> job done
[18:36:18 CEST] <wm4> many of these issues are probably because the API was designed for synchronous operation
[18:36:29 CEST] <wm4> while these OS-level things are designed for asynchronous
[20:20:54 CEST] <peloverde> Is there a decimation filter that just supports a dumb frame pattern and doesn't try to do matching?
[20:32:01 CEST] <durandal_1707> peloverde: select?
[20:33:18 CEST] <peloverde> that's the one, thanks
[20:58:42 CEST] <cone-534> ffmpeg 03Ronald S. Bultje 07master:2fb593dcb90c: Put remaining pieces of CODEC_FLAG_EMU_EDGE under FF_API_EMU_EDGE.
[21:00:45 CEST] <cone-534> ffmpeg 03Ronald S. Bultje 07master:7e12a5425114: ffserver: use -b instead of -ab for setting audio bitrate.
[21:05:45 CEST] <cone-534> ffmpeg 03Paul B Mahol 07master:777df1ff746e: avfilter/vf_dejudder: use the name 's' for the pointer to the private context
[23:20:16 CEST] <cone-534> ffmpeg 03Michael Niedermayer 07master:628a73f8f376: ffmpeg: force 128k default audio bitrate if nothing is specified and there is no specific default
[00:00:00 CEST] --- Sat Aug 29 2015
1
0
[00:25:38 CEST] <CraziFuzzy> DHE, thanks for the help. I think I stumbled upon a much simpler way to do things. instead of having ffmpeg write to a file, I can probably have ffmpeg pipe its output to a very simple program that writes x of it's stdin bytes to a file, then moves its pointer to the beginning and continues writing.
[03:30:19 CEST] <k_sze> If, after decoding a frame, I perform a sws_scale to convert it to another pixel format, what's the best way to copy the "metadata" from the source AVFrame to the destination AVFrame?
[03:30:28 CEST] <k_sze> Does ffmpeg have a function for that?
[03:32:19 CEST] <k_sze> (because after sws_scale from a srcFrame to a dstFrame, dstFrame only has pixel data, but no metadata such as the pts/dts of dst, and I want to preserve those.
[03:33:47 CEST] <k_sze> s/pts\/dts of dst/pts\/dts of srcFrame/
[03:35:20 CEST] <k_sze> I probably could copy manually, but it would be nice if ffmpeg has a function that copies metadata so I don't miss anything meaningful.
[09:19:10 CEST] <k_sze> So I'm reading this: http://ffmpeg.org/doxygen/2.5/group__lavc__decoding.html#ga99ee61b6dcffb781…
[09:19:43 CEST] <k_sze> I notice it says: "When AVCodecContext.refcounted_frames is set to 0, the returned reference belongs to the decoder and is valid only *until the next call to this function or until closing or flushing the decoder*."
[09:20:06 CEST] <k_sze> What does it really mean? "until the next call to this function or until closing or flushing the decoder"???
[09:20:16 CEST] <k_sze> Whichever happens last for the current packet?
[09:36:12 CEST] <jules> hey, is there a way to get the current decoder frame rate / bit rate from the c API?
[10:39:50 CEST] <thecoolguy> if i seperate outputs by \
[10:40:01 CEST] <thecoolguy> is there 2 sperate encoding operations happening ?
[11:13:57 CEST] <thecoolguy> fflogger http://pastie.org/private/zgqiztveeaulpjyo8ar1xa
[11:16:47 CEST] <thecoolguy> what am i doing wrong?
[11:48:43 CEST] <fAmp> HI there,
[11:48:48 CEST] <fAmp> i have a question
[11:49:08 CEST] <fAmp> if i try to ps -aux | grep ffmpeg, the process is show 0.00 cpu usage
[11:49:52 CEST] <fAmp> i want to monitor this application, is there anyone that have any ide how to get that information working but just simple commands ?
[11:51:01 CEST] <a_functionalist> hello, I have one question. When opening a file with the -re option and pipe output, then ffmpeg doesn't wait until the receiver begins to read in data. without the -re option, ffmpeg does wait though. does anyone know how to get it to wait even with -re enabled?
[12:03:46 CEST] Last message repeated 1 time(s).
[12:03:46 CEST] <a_functionalist> (sorry for possible double post, was disconnected)
[13:55:21 CEST] <a_functionalist> hello can someone confirm that you set the blocksize option of an output pipe like this? pipe:1?blocksize=256
[13:55:35 CEST] <a_functionalist> the reason why i ask is, because blocksixxxxx=256 works as well.
[13:55:52 CEST] <a_functionalist> with it works I mean that ffmpeg won't show an error like: invalid option
[13:58:02 CEST] <teddythetwig> Hey yall, anyone here on UTC +2:00?
[16:45:08 CEST] <NapoleonWils0n> hi guys
[16:45:31 CEST] <NapoleonWils0n> just tring to use ffplay but get an error about SDL_AUDIODRIVER
[16:45:57 CEST] <NapoleonWils0n> im tying to use alsa audio, tried export SDL_AUDIODRIVER=alsa and export AUDIODEV=hw:1,0
[19:02:15 CEST] <DrBenway> i've trancoded a file using libavformat and the output file plays in vlc but not in windows media player
[19:02:26 CEST] <DrBenway> is there soemthing that i can do to get errors from the file?
[19:03:28 CEST] <DrBenway> basically i want to diagnose what went wrong with my mp4
[19:09:42 CEST] <FlorianBd> DrBenway: that would not really be ffmpeg's concern, the only thing you can do IMO is to use ffprobe to see exactly which format/codecs this file is using
[19:10:10 CEST] <DrBenway> any specific flags to ffprobe?
[19:10:45 CEST] <FlorianBd> https://www.ffmpeg.org/ffprobe.html
[19:18:30 CEST] <DrBenway> yeah i can read, my point is that there're a lot of flags and maybe some of them are better for debugging in my tyope of situation
[19:18:44 CEST] <c_14> DrBenway: you probably won't need any, maybe -show_format
[19:19:10 CEST] <llogan> -show_streams probably too
[19:19:43 CEST] <DrBenway> k
[19:37:43 CEST] <frenda> Is x265 supported by ffmpeg?
[19:38:08 CEST] <llogan> yes
[19:38:09 CEST] <frenda> Can I replace libx264 with libx265 here: https://trac.ffmpeg.org/wiki/Capture/Desktop ?
[19:38:22 CEST] <llogan> yes, if your build supports it
[19:39:04 CEST] <llogan> and the crf values will probably be different
[19:39:58 CEST] <llogan> any maybe presets/tunes too
[19:54:09 CEST] <frenda> How can I check is it supported otr not by my build? I've installed it via package manager ion fedora
[19:54:12 CEST] <frenda> in*
[19:54:21 CEST] <frenda> or*
[19:56:56 CEST] <c_14> ffmpeg -encoders
[19:59:22 CEST] <frenda> Yoohoo
[19:59:26 CEST] <frenda> V..... libx265 libx265 H.265 / HEVC (codec hevc)
[19:59:53 CEST] <frenda> Now, where I should I add lib x265 in this command:
[19:59:57 CEST] <frenda> `ffmpeg -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0+100,200 output.mp4`
[20:00:07 CEST] <c_14> -c:v libx264 before output.mp4
[20:00:17 CEST] <JEEB> or more exactly, after -i
[20:00:22 CEST] <JEEB> and before the output
[20:01:14 CEST] <frenda> tnx
[20:05:46 CEST] <frenda> Stream #0:0 -> #0:0 (rawvideo (native) -> hevc (libx265))
[20:05:47 CEST] <frenda> Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[20:06:28 CEST] <c_14> There's usually another error hidden somewhere up
[20:08:39 CEST] <frenda> c_14: yeah: 4:2:2 and 4:4:4 support is not fully defined for HEVC yet. Set -strict experimental to encode anyway.
[20:08:44 CEST] <frenda> it's one line error
[20:09:10 CEST] <c_14> so either set -strict experimental or use -pix_fmt yuv420p
[20:12:42 CEST] <JEEB> frenda: it has been for quite a while
[20:13:15 CEST] <JEEB> it was added in HEVC/H.265 version 2 (range extensions)
[20:13:21 CEST] <JEEB> and we're at version 3 by now
[20:13:37 CEST] <JEEB> libx265 had that warning for a while but that was removed quite some time ago as well
[20:13:50 CEST] <JEEB> which means that if you _now_ get that warning, then you are using a very old version of libx265
[20:14:26 CEST] <c_14> Hmm, don't think the patch was applied to ffmpeg yet
[20:14:28 CEST] <c_14> It's on the ml though
[20:15:07 CEST] <JEEB> the ML one was about 12bit I think
[20:15:18 CEST] <JEEB> which is a very recent feature in libx265
[20:15:34 CEST] <JEEB> 4:2:2/4:4:4 have been in libx265 for quite a while by now
[20:15:45 CEST] <c_14> The one I'm looking at is about 4:2:2 and 4:4:4. From the 22nd
[20:15:55 CEST] <JEEB> o_O
[20:15:59 CEST] <JEEB> really?
[20:16:07 CEST] <JEEB> I remembered there was one for 12bit
[20:16:14 CEST] <JEEB> since that lost its warning in libx264 a few days ago
[20:16:20 CEST] <c_14> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177709.html
[20:16:49 CEST] <c_14> Ah, the 12-bit was PATCH 2/2
[20:16:59 CEST] <JEEB> wow
[20:17:05 CEST] <JEEB> 4:2:2/4:4:4
[20:17:08 CEST] <JEEB> ok
[20:17:09 CEST] <JEEB> so yes
[20:18:13 CEST] <JEEB> I guess it shows how much people cared :D
[20:19:25 CEST] <JEEB> that said
[20:19:33 CEST] <JEEB> I'd be surprised if libx265 was fast enough for screen capture
[20:27:48 CEST] <frenda> It's saying `Press [q] to stop, [?] for help`
[20:27:51 CEST] <frenda> I do it
[20:28:05 CEST] <frenda> but it does not stop filming instantly!
[20:28:54 CEST] <frenda> Is it because of libx265?
[20:29:18 CEST] <c_14> It won't be instantaneous, but it should be relatively fast.
[20:30:13 CEST] <frenda> It's over 1 minute I have pressed `q`, but it has not returned to prompt!
[20:30:26 CEST] <c_14> Hmm, try ^c
[20:30:56 CEST] <frenda> I did it once. It destroyed the video!
[20:31:18 CEST] <frenda> Ah, it stoped! over 2 minutes!
[20:31:38 CEST] <c_14> Pressing it once should make it do a regular termination
[00:00:00 CEST] --- Sat Aug 29 2015
1
0
[00:14:53 CEST] <cone-346> ffmpeg 03Paul B Mahol 07master:0190c372ef79: avfilter/framesync: allocate FFFrameSyncIn internally
[00:14:53 CEST] <cone-346> ffmpeg 03Paul B Mahol 07master:319440e54f47: avfilter: add hstack & vstack filter
[01:48:10 CEST] <michaelni> kierank, did you see "Marina Zhurakhi (1.6K) [Outreachy Announce] [COORDINATION] internships completion feedback from mentors due Friday, August 28"
[03:01:21 CEST] <cone-346> ffmpeg 03Carl Eugen Hoyos 07master:7f9656f10df5: lavc/dnxhdenc: Fix ibias default.
[03:31:50 CEST] <cone-346> ffmpeg 03Carl Eugen Hoyos 07master:33908f08377d: lavf/mov: Support unusual alac files without frma and alac atoms.
[03:47:12 CEST] <cone-346> ffmpeg 03Timothy Gu 07master:da0e76955a08: ffmpeg_opt: Add -hwaccels option that lists all supported hwaccels
[04:39:52 CEST] <cone-346> ffmpeg 03Michael Niedermayer 07master:81a8701eb52d: avformat/oggenc: Check segments_count for headers too
[09:20:29 CEST] <cone-386> ffmpeg 03Vittorio Giovara 07master:fdd021884d5c: dnxhddata: Keep a single CID in the table names
[09:20:29 CEST] <cone-386> ffmpeg 03Vittorio Giovara 07master:d3ae4c65942d: dnxhddata: List the reused tables in a comment
[09:20:29 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:bd074bde02aa: Merge commit 'fdd021884d5c06fb9ad65cb0040bb5717a7b084b'
[09:20:29 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:3f491224fe7f: Merge commit 'd3ae4c65942d67a294fd56eabbbdcce6756fab5f'
[09:29:42 CEST] <cone-386> ffmpeg 03Vittorio Giovara 07master:5e129ed655bf: dnxhddata: Group together DC-related tables
[09:29:43 CEST] <cone-386> ffmpeg 03Vittorio Giovara 07master:403ea4ac7289: dnxhddata: Merge a few duplicated DC tables
[09:29:44 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:3b0af76c1b43: Merge commit '5e129ed655bff5b6d90355c0b713d7aaba3898ec'
[09:29:45 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:305f46175429: Merge commit '403ea4ac7289ac39229452b6b5e2f8ebcc00f2a1'
[09:34:39 CEST] <cone-386> ffmpeg 03Vittorio Giovara 07master:efbfb1ad1112: dnxhddata: Group together RUN-related tables
[09:34:40 CEST] <cone-386> ffmpeg 03Vittorio Giovara 07master:a4615572b576: dnxhddata: Merge a few duplicated RUN tables
[09:34:41 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:f19a2838678e: Merge commit 'efbfb1ad1112cea79bef51fd9f30c0c94735abfc'
[09:34:42 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:f30132f9c406: Merge commit 'a4615572b576d3ef7ee2f11529d935e61bf4ebb8'
[09:40:21 CEST] <cone-386> ffmpeg 03Vittorio Giovara 07master:d68705c9756e: dnxhddata: Add tables for missing DNx100 profiles
[09:40:22 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:427598a2f423: Merge commit 'd68705c9756e6558c8e28d90b4c364f25ba72083'
[09:49:55 CEST] <cone-386> ffmpeg 03Luca Barbato 07master:2157df425bd9: hlsenc: Support outputting specific versions
[09:49:56 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:540f2800980e: Merge commit '2157df425bd909854fd4afcec4aa3311d8a3b31b'
[09:51:29 CEST] <cone-386> ffmpeg 03Luca Barbato 07master:413d4e54a9bf: nvenc: Properly free the fifos
[09:51:30 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:ebff705c2c55: Merge commit '413d4e54a9bffe2d0afdc6d8a80f516e5df6a421'
[09:53:24 CEST] <cone-386> ffmpeg 03Luca Barbato 07master:e176639bcbf4: webm: Explicitly select libvpx, libopus and libvorbis encoders
[09:53:25 CEST] <cone-386> ffmpeg 03Hendrik Leppkes 07master:f5258a7d16d0: Merge commit 'e176639bcbf4b580edb462a6b0650e53cd5e3c04'
[10:44:14 CEST] <wm4> j-b: looks like I could make it to VDD on Saturday
[10:44:28 CEST] <wm4> I still need to get a flight though
[10:57:43 CEST] <wm4> j-b: let me know if I can be confirmed as participating, and I need a room as well
[11:42:50 CEST] <anshul_> While decoding Closed caption from mov, Closed Caption gets some atom header from mov demuxer
[11:44:19 CEST] <anshul_> where are all atom registered and opinion where could be the problem
[11:44:34 CEST] <j-b> wm4: of course, you are confirmed.
[11:44:39 CEST] <j-b> wm4: please mail me all the info.
[11:54:14 CEST] <wm4> j-b: what info do you need? anyway, I still need to find a flight
[11:55:20 CEST] <j-b> You need to register online. And then mail me the nights where you must have a hotel.
[11:58:04 CEST] <wm4> I should be there on saturday and sunday, right?
[11:58:11 CEST] <j-b> that'd be better, yes
[12:12:45 CEST] <cone-386> ffmpeg 03Ganesh Ajjanagadde 07master:f174bfea86b3: configure: remove unused apply() function
[12:33:10 CEST] <wm4> j-b: and when on saturday does it start / when does it end on sunday?
[13:10:16 CEST] <cone-386> ffmpeg 03Michael Niedermayer 07master:6701c92fa426: avcodec/libopusenc: Fix infinite loop on flushing after 0 input
[13:44:42 CEST] <j-b> wm4: 9h30 - around 16h00
[13:44:51 CEST] <j-b> wm4: but Sunday is more relaxed for schedule.
[13:49:24 CEST] <wm4> ok, saturday 9.30 AM to sunday 4 PM
[13:54:37 CEST] <j-b> more or less
[15:14:46 CEST] <BBB> wm4: youre coming?
[15:14:47 CEST] <BBB> \o/
[15:30:34 CEST] <wm4> maybe
[16:04:48 CEST] <BtbN> philipl, nevcairiel, as gb is aparently gone for now, i'm not expecting a review of the hevc patch anytime soon. Any objections against just pushing it?
[16:05:10 CEST] <BtbN> Or should i wait for gb, as he's listed as vaapi maintainer?
[16:31:24 CEST] <philipl> i would push it. its useful enough for the real world
[16:32:31 CEST] <philipl> and he considers the gst plugin shippable with the same conformance failures.
[16:36:01 CEST] <BtbN> I'm at a point now where i don't know what else to change or improve. It works for all samples i tested except for the SLIST ones, which are also broken in gst.
[16:36:34 CEST] <wm4> with some luck it's a hardware bug?
[16:36:45 CEST] <BtbN> Or just a bug in libva
[16:36:50 CEST] <BtbN> That's not too uncommon
[16:38:09 CEST] <BtbN> The ScalingLists ffmpeg generates are very diffrent from the ones gst produces though
[16:38:16 CEST] <BtbN> but they produce the same artifacts
[16:40:16 CEST] <nevcairiel> wm4: not hardware, it works through other APIs, but libva maybe
[16:40:53 CEST] <BtbN> You mean it works through QSV?
[16:40:56 CEST] <BtbN> Or what other API?
[16:41:38 CEST] <nevcairiel> dxva
[16:41:39 CEST] <BtbN> Oh, just noticed. Does it need a Changelog entry?
[16:41:49 CEST] <BtbN> Ah, on windows. Sure. Didn't think of that.
[16:42:02 CEST] <nevcairiel> dont we have a qsv decoder too?
[16:42:06 CEST] <nevcairiel> i suppose you could try that
[16:42:23 CEST] <BtbN> I still would have to register at Intel to download the SDK.
[16:42:44 CEST] <BtbN> Did you test in on a Cherryview GPU, or on one where it's decoded via shaders?
[16:43:32 CEST] <nevcairiel> on skylake
[16:43:47 CEST] <nevcairiel> so hardware decoding
[16:43:52 CEST] <cone-386> ffmpeg 03Carl Eugen Hoyos 07master:0382c546cc93: lavc: Describe eia_608 as text subtitles.
[16:43:54 CEST] <nevcairiel> of course it could be a different hardware than in those atoms
[16:44:01 CEST] <nevcairiel> dont have one of those handy
[16:44:05 CEST] <BtbN> No, same GPU iirc
[16:44:29 CEST] <nevcairiel> last i heard, those atoms used the broadwell gpu, but with an improved media processor
[16:44:37 CEST] <nevcairiel> so something in between broadwell and skylake
[16:44:48 CEST] <nevcairiel> In any case, I would also just push it
[16:45:00 CEST] <nevcairiel> my dxva patch had totally broken scaling lists initially =p
[16:45:18 CEST] <BtbN> It does the exact same thing dxva and vdpau do for them
[16:45:28 CEST] <BtbN> I can't imagine it's that wrong.
[16:45:38 CEST] <nevcairiel> unless it wants something else
[16:45:45 CEST] <nevcairiel> but that would be weird
[16:45:57 CEST] <BtbN> It just refers to the HEVC spec in that struct
[16:46:02 CEST] <BtbN> As does DXVA
[16:46:08 CEST] <BtbN> so i'd guess they expect the same stuff
[16:46:42 CEST] <BtbN> What about the Changelog entry? Does it need one? Can't see one for other hwaccel related changes.
[16:46:54 CEST] <nevcairiel> just add one, makes everyone happy
[16:47:05 CEST] <nevcairiel> maybe a minor bump too
[16:54:15 CEST] <BtbN> god damn it kodi. "I was inactive for an hour, shutdown the system"
[16:55:59 CEST] <philipl> nevcairiel: can you run vainfo on uour skylake box?
[16:56:11 CEST] <philipl> i want to know if it claims vp9 support
[16:56:14 CEST] <nevcairiel> its not mine really, i just had access to one for a bit
[16:56:25 CEST] <nevcairiel> (and it runs windows :D)
[16:56:47 CEST] <wm4> my desktop is a skylake box, but no idea how to make it use intel graphics (using nvidia, better drivers)
[16:56:53 CEST] <BtbN> https://bpaste.net/show/e9143aaa83f8 that's on my NUC
[16:56:59 CEST] <BtbN> wm4, you don't have to make it use intel drivers
[16:57:09 CEST] <philipl> wm4, just run vainfo
[16:57:12 CEST] <wm4> BtbN: vainfo for one dumps only the nvidia info
[16:57:20 CEST] <philipl> ah wrll
[16:57:31 CEST] <BtbN> Does the intel card show up in /dev/dri?
[16:57:41 CEST] <nevcairiel> but they do offer vp9 decoding through qsv .. and presumably they have a dxva2 device id for vp9, but microsoft didnt specify a standard for vp9, so intel uses some proprietary format, and of course they dont disclose that
[16:57:44 CEST] <wm4> there's a card0, nothing else
[16:57:56 CEST] <philipl> you need x connected to the driver for vainfo to work
[16:58:02 CEST] <wm4> philipl: yep
[16:58:02 CEST] <BtbN> you don't
[16:58:10 CEST] <BtbN> It works without X
[16:58:15 CEST] <wm4> using DRM?
[16:58:16 CEST] <philipl> didnt work headless for me
[16:58:17 CEST] <BtbN> yes
[16:58:26 CEST] <BtbN> works on my server, which has no X installed
[16:58:30 CEST] <wm4> then I probably need to force vainfo to load the correct driver
[16:58:41 CEST] <nevcairiel> you may need to turn the GPU on in the BIOS
[16:58:59 CEST] <nevcairiel> something like multi-monitor support with dedicated GPU or something
[16:59:07 CEST] <nevcairiel> otherwise it just turns it off when a dedicated GPU is installed
[16:59:16 CEST] <nevcairiel> (may depend on motherboard)
[16:59:20 CEST] <wm4> running vainfo on the terminal complains it can't connect to X
[16:59:32 CEST] <wm4> (I mean, on a console where DISPLAY is not set)
[16:59:42 CEST] <BtbN> It does so for me, too
[16:59:45 CEST] <BtbN> but then lists the info anyway
[16:59:49 CEST] <BtbN> because of drm fallback
[16:59:49 CEST] <nevcairiel> heh
[16:59:58 CEST] <cone-386> ffmpeg 03Ganesh Ajjanagadde 07master:bfe525e6328e: configure: warn if GCC 4.2 is being used
[17:00:16 CEST] <wm4> I've actually run vainfo on intel drivers once
[17:00:20 CEST] <wm4> maybe I can find it again
[17:00:40 CEST] <BtbN> It's some environment var to force the intel driver
[17:00:58 CEST] <nevcairiel> I wish i knew someone related to windows intel driver/media thingys, then I could pester them to release the vp9 dxva2 structures they are using
[17:01:33 CEST] <wm4> found it: http://sprunge.us/ZTLG
[17:01:38 CEST] <wm4> it can do VP8 trollol
[17:02:10 CEST] <philipl> oh yeah, no one addwd vp9 to vainfo
[17:02:11 CEST] <nevcairiel> someone also asked me about (M)JPEG decoding through DXVA
[17:02:23 CEST] <nevcairiel> but again, only intel proprietary format, no official docs :(
[17:02:23 CEST] <philipl> so that proves nithing
[17:02:25 CEST] <philipl> gah
[17:02:34 CEST] <wm4> apparently web browsers can make good use of jpeg hw decoding
[17:02:34 CEST] <BtbN> Does ffmpeg support that through libva?
[17:02:44 CEST] <philipl> no.
[17:02:52 CEST] <BtbN> That shouldn't be too hard to add
[17:02:53 CEST] <philipl> btbn: add mjpeg!
[17:03:05 CEST] <BtbN> jpeg is fairly simple, compared to hevc
[17:03:12 CEST] <philipl> just a bit
[17:03:56 CEST] <philipl> my cunning plan is to get support for all vaapi codecs to make nvidia add them to vdpau to keep up
[17:04:11 CEST] <nevcairiel> does nvidias hardware do those
[17:04:16 CEST] <nevcairiel> otherwise they seem unlikely to be interested
[17:04:40 CEST] <philipl> they do
[17:05:32 CEST] <nevcairiel> its a shame that Microsoft is unlikely to specify them officially through dxva
[17:05:51 CEST] <wm4> btw. many vdpau cards can do many of those DIVX profiles...
[17:06:44 CEST] <cone-386> ffmpeg 03Timo Rothenpieler 07master:1dd854e10fe1: vaapi: Add hevc hwaccel support
[17:06:50 CEST] <nevcairiel> \o/
[17:07:10 CEST] <nevcairiel> show them kodi devs that are apparently working on this too!
[17:07:28 CEST] <philipl> heh. i mentioned kodi tl thwm.
[17:07:28 CEST] <wm4> those kodi devs should show up on this channel more often
[17:07:33 CEST] <wm4> instead of doing private changes
[17:07:53 CEST] <BtbN> nevcairiel, i was working on this because team kodi gave me that NUC, asking me to add vaapi hevc hwaccel to ffmpeg.
[17:08:00 CEST] <philipl> they were pleasant enough working with me.
[17:08:04 CEST] <nevcairiel> maybe that guy was just confused then
[17:08:11 CEST] <philipl> im pretty sure they arw not doing anuthing.
[17:08:30 CEST] <philipl> that guy thinks btbn is a kodi guu
[17:08:33 CEST] <philipl> guy
[17:08:39 CEST] <BtbN> hm?
[17:08:45 CEST] <philipl> fucking ipad
[17:08:49 CEST] <BtbN> which guy?
[17:08:55 CEST] <nevcairiel> one guy used that as an excuse why his tickets arent being answered, apparently the kodi devs are busy with vaapi hevc and cant
[17:09:07 CEST] <philipl> right
[17:09:09 CEST] <BtbN> the hell
[17:09:26 CEST] <wm4> he mentioned someone named FernetMenta?
[17:09:31 CEST] <wm4> or something
[17:09:44 CEST] <BtbN> Fernet and fritsch are the primary people pushing vaapi in kodi.
[17:09:45 CEST] <philipl> thats their main linux guy
[17:10:06 CEST] <BtbN> They did some amazing work. kodi plays 4K60 on my NUC.
[17:10:13 CEST] <BtbN> hevc
[17:10:30 CEST] <nevcairiel> direct rendering can do magix
[17:10:36 CEST] <philipl> with the egl insanity
[17:10:38 CEST] <nevcairiel> only took linux a couple years
[17:10:50 CEST] <BtbN> well, only took intel open source devs a couple years.
[17:10:52 CEST] <philipl> only took intel
[17:10:55 CEST] <philipl> yeah
[17:10:56 CEST] <BtbN> Their GLX implementation was butchered
[17:11:15 CEST] <BtbN> It was faster to copy to system ram and re-opload to an OpenGL texture than to use their GLX interop
[17:12:16 CEST] <wm4> nevcairiel: vdpau GL interop always worked
[17:12:32 CEST] <BtbN> yes, they have actual GL extensions handling it
[17:13:02 CEST] <wm4> I'm curious about the new EGL interop... I'll try it as soon as my drivers are probably new enough
[17:13:11 CEST] <BtbN> you need mesa-11 for it
[17:13:32 CEST] <wm4> I'm using debian, so maybe in a few years
[17:13:40 CEST] <BtbN> you can propably just add the kodi repository
[17:13:51 CEST] <BtbN> They have all the stuff needed there, for various deb based distros
[17:13:57 CEST] <nevcairiel> thats really my main gripe with linux, i need to support like 3 different API combinations to get video things going :D
[17:14:09 CEST] <philipl> BtbN: so you want to add vp8? I've got an 'in theory' patch locally to add hwaccel hooks for that and vp9.
[17:14:29 CEST] <BtbN> Yeah, mjpeg and vp8 would definitely be nice to have.
[17:14:30 CEST] <philipl> otherwise I'll do it when I finally get a skylake machine
[17:15:01 CEST] <BtbN> Can't do vp9 though, my nuc doesn't seem to support it.
[17:15:17 CEST] <nevcairiel> might be a driver or libva thing
[17:15:30 CEST] <nevcairiel> or its really only skylake
[17:15:34 CEST] <philipl> only skylake
[17:15:43 CEST] <philipl> That's what intel have said publicly.
[17:15:45 CEST] <nevcairiel> the atom nucs are somewhere in between on compat
[17:15:50 CEST] <nevcairiel> broadwell doesnt do hevc
[17:15:56 CEST] <nevcairiel> but the atom uses the broadwell gpu
[17:15:58 CEST] <nevcairiel> yet does hevc
[17:16:02 CEST] <philipl> braswell
[17:16:02 CEST] <wm4> wait, skylake has vp9?
[17:16:17 CEST] <philipl> skylake has hybrid vp9. uses shaders for part of it
[17:16:48 CEST] <nevcairiel> codec support: http://abload.de/img/5a4q2x.png
[17:16:51 CEST] <BtbN> If you have the 3000$ Intel Media SDK, it comes with a libva driver that does hevc on ivy bridge or better.
[17:17:21 CEST] <philipl> wm4. You need to patch vainfo to try and detect vp9, then we'll know for sure.
[17:17:50 CEST] <BtbN> Wait, it doesn't check for that?
[17:17:54 CEST] <wm4> just tell me what I should try, and I'll do it
[17:18:43 CEST] <BtbN> vainfo already seems to check for VAProfileVP9Profile0
[17:18:57 CEST] <philipl> Hmm. In a released version?
[17:19:06 CEST] <BtbN> just looked at git master
[17:19:54 CEST] <philipl> 14 daysAdd VP9 profile to vainfoHEADmaster
[17:19:59 CEST] <philipl> Yeah, it's the last change made in git.
[17:20:06 CEST] <BtbN> It seems to be rather generic. If the driver reports a profile vainfo doesn't know, it would print <unknown profile>
[17:20:07 CEST] <philipl> wm4: so check it out and build it, then try again
[17:20:19 CEST] <philipl> I WILL KEEP HOPING
[17:28:02 CEST] <cone-386> ffmpeg 03lummax 07master:0c800b27611c: avcodec: Assert on codec->encode2 in encode_audio2
[17:28:37 CEST] <wm4> debian must be doing something stupid
[17:28:56 CEST] <wm4> e.g. the vdpau driver is in /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
[17:29:05 CEST] <wm4> while vainfo expects /usr/lib/dri/...
[17:30:05 CEST] <iive> that's their multiarch setup
[17:30:15 CEST] <wm4> and it's retarded
[17:30:39 CEST] <wm4> no purpose and actually causes tons of problems
[17:31:13 CEST] <iive> imho, it is better that lib64 and lib32a
[17:31:20 CEST] <wm4> ok, LIBVA_DRIVERS_PATH
[17:31:57 CEST] <j-b> BBB: ping
[17:32:04 CEST] <BBB> j-b: pong
[17:38:21 CEST] <wm4> meh, the va tools helper code has code for selecting a display type per command line, but vainfo doesn't use it
[17:39:00 CEST] <wm4> ok, via DRM it apparently just doesn't work
[17:39:19 CEST] <wm4> libva info: va_getDriverName() returns -1
[17:39:19 CEST] <wm4> libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
[17:39:19 CEST] <wm4> vaInitialize failed with error code -1 (unknown libva error),exit
[17:55:33 CEST] <philipl> wm4: intel don't want us to know.
[18:03:09 CEST] <wm4> either I really have to enable it in the BIOS, or I have to load/instal some obscure driver?
[18:05:24 CEST] <philipl> it has to be enabled in the bios for sure.
[18:06:04 CEST] <wm4> shouldn't Linux be able to use the hw anyway?
[18:06:25 CEST] <wm4> I don't think the BIOS allows enabling both
[18:06:44 CEST] <wm4> so I'd have to reboot Linux, which I don't want to
[18:06:50 CEST] <wm4> (lots of open windows etc.)
[18:08:01 CEST] <philipl> you can enable both but it'll be messy.
[18:08:16 CEST] <wm4> messy?
[18:08:18 CEST] <philipl> don't worry, ill continue to live in ignorance.
[18:08:44 CEST] <wm4> well I can do it the next time I want to reboot, and maybe there are some other skylake users around
[18:08:46 CEST] <philipl> will x come up right etc
[18:08:51 CEST] <wm4> or maybe I could boot a live CD
[18:09:16 CEST] <philipl> live cd would be best but need to move monitor
[18:09:47 CEST] <wm4> the main problem with the live cd is that I'd need to compile vainfo
[18:10:07 CEST] <philipl> true
[18:10:29 CEST] <philipl> might also need to build up to date va driver too
[18:27:45 CEST] <cone-386> ffmpeg 03Stefano Sabatini 07master:57cd2f7777a3: lavf/mpegenc: provide better feedback in case of invalid media type
[20:01:53 CEST] <philipl> BtbN: __gb__ didn't take the bait on the TODO items. Guess he wants someone else to work it out :-)
[20:02:58 CEST] <philipl> http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-VAAPI-Samsung-Pa…
[20:03:01 CEST] <philipl> THe circle is complete!
[20:31:36 CEST] <wm4> philipl: the fuck
[20:33:13 CEST] <wm4> why would they be interested in this? makes no sense to me
[20:40:03 CEST] <wm4> ubitux: there's no way yet to distinguish subs with 0 and unknown length yet, correct?
[21:48:41 CEST] <philipl> wm4: boggles my mind. Why vaapi when vdpau works. Why Samsung. So many questions.
[21:50:10 CEST] <Compn> samsung sponsored some stuff for ffmpeg , maybe opw?
[21:50:17 CEST] <Compn> so they are our friends
[21:50:18 CEST] <Compn> :P
[21:54:32 CEST] <michaelni> philipl, if you have questions related to samsung, then ask reynaldo
[21:56:21 CEST] <Daemon404> IME people working for bigcorps rarely know why another division has done something
[22:00:51 CEST] <cone-386> ffmpeg 03Paul B Mahol 07master:15f4b3db58a6: avfilter: add framerate video filter
[22:03:10 CEST] <michaelni> true but they should know who to contact or ask at least if there is interrest
[22:05:24 CEST] <llogan> durandal_1707: looks like an interesting one
[22:06:53 CEST] <durandal_1707> its buggy...
[22:33:23 CEST] <philipl> Just seems highly masochistic. nouveau has working vdpau - so why would anyone want to fight with vaapi.
[22:33:38 CEST] <Daemon404> philipl, because a manager told you to
[22:33:46 CEST] <Daemon404> looks good at trade shows
[22:33:47 CEST] <Daemon404> who knows.
[22:33:56 CEST] <philipl> I guess if your applications are all based on gstreamer you might, as there's no vdpau worth a damn in gstreamer.
[22:34:16 CEST] <philipl> but I'd rather write a vdpau plugin for gstreamer than add vaapi to a driver.
[22:35:39 CEST] <nevcairiel> Does media capability and OpenGL rendering even work good enough in nouveau to care?
[22:36:22 CEST] <nevcairiel> I haven't used it for a year or so now, but it used to be quite lacking
[22:36:56 CEST] <Daemon404> well also
[22:37:01 CEST] <philipl> My perceptions are mostly historical, when it was unusable. I believe it can be used in more situations now, but why is the eternal question.
[22:37:07 CEST] <Daemon404> i know 0 people using nouveau, not including MUH FREEDUMS types
[22:37:19 CEST] <philipl> quite.
[22:37:40 CEST] <nevcairiel> Presumably nvidia is even working on KMS now for the binary blob
[22:38:07 CEST] <philipl> Possibly KMS. They were trying to push that EGL Streams thing as an alternative for wayland.
[22:38:18 CEST] <philipl> Last I heard they'd given up and were working on KMS
[22:38:34 CEST] <wm4> nevcairiel: nouveau can destroy your hardware physically
[22:38:46 CEST] <wm4> (power management is hard)
[22:38:47 CEST] <philipl> but it was free before it died.
[22:39:01 CEST] <nevcairiel> If you listen to the internet, so can the windows driver on certain laptops
[22:39:30 CEST] <nevcairiel> Technically it destroys the screen there, same diff
[23:04:52 CEST] <cone-386> ffmpeg 03Ganesh Ajjanagadde 07master:9ba511d5d3d7: avfilter/af_amerge: use the name 's' for the pointer to the private context
[00:00:00 CEST] --- Fri Aug 28 2015
1
0
[00:49:35 CEST] <Phr33d0m> hi, I'm trying to output screenshots from a mkv file yet I also want the subtitles (probably ass or ssa codec) to be printed as well on the screenshot
[00:50:09 CEST] <Phr33d0m> I've tried `ffmpeg -ss 22:35 -i somevideo.mkv -t 51 -s 720x480 -map 0 -map -0:a -scodec ssa -f image2 /tmp/%03d.png` changing ssa for ass without success
[02:07:07 CEST] <guest4377> does ffmpeg enforce some limit on png dimensions?
[02:07:27 CEST] <guest4377> I'm trying to encode a 65536x65536 image, but it says "[png @ 03f29060] [IMGUTILS @ 0022f334] Picture size 65536x65536 is invalid"
[02:20:21 CEST] <kepstin> lets see... that's hitting the limit in av_image_check_size
[02:20:51 CEST] <kepstin> which is approximately height * width must be less than 1/8th the value of INT_MAX
[02:21:12 CEST] <kepstin> i'm guessing it's a protection against overly large memory allocations
[02:23:03 CEST] <kepstin> you do realize that a 65536x65536 image would require 16gb of ram to store decoded, right?
[02:23:18 CEST] <kepstin> (assuming rgba or rgb0)
[02:25:44 CEST] <tommd> Some people do have 1TB machines, it doesn't seem entirely unreasonable that someone might have a large use case.
[02:26:13 CEST] <kepstin> I suspect that increasing the max image size in ffmpeg would require very careful auditing of a lot of code paths to switch to 64bit values.
[02:27:22 CEST] <Plorkyeran> or just bump it and wait for the CVEs to roll in
[02:29:47 CEST] <guest4377> so what is the actual maximum usable?
[02:31:08 CEST] <guest4377> how do I find out how much is INT_MAX in my system? or is it a variable somewhere in ffmpeg?
[02:31:23 CEST] <kepstin> the actual maximum usable is such that the (height + 128) * (width + 128) is less than 268435455 on most systems ffmpeg supports
[02:31:50 CEST] <guest4377> oh well
[02:32:02 CEST] <guest4377> that's going to require some maths from me to calculate
[02:32:07 CEST] <guest4377> anyways, thank you
[02:32:32 CEST] <kepstin> which more or less means, the image + overhead of a 64bit per pixel image would fit in 2gb
[04:27:49 CEST] <k_sze> Does anybody know some kind of push-based streaming container/protocol (that FFmpeg happens to support out of the box)?
[04:28:27 CEST] <k_sze> As in, if I want to encode some video and I want to *push* the video stream to a remote computer.
[04:31:29 CEST] <k_sze> Instead of the remote computer pulling (protocols like RTSP/RTP are pull-based, if I understand correctly).
[06:19:09 CEST] <Max-P> k_sze_: There's the udp:// and tcp:// raw protocols
[06:20:11 CEST] <Max-P> And rtmp:// now that I think of it
[06:20:24 CEST] <k_sze_> rtmp can be push-based?
[06:20:32 CEST] <Max-P> Yes
[06:20:59 CEST] <Max-P> I have an nginx server listening to connections, and when I want to stream I ffmpeg to it
[06:21:53 CEST] <Max-P> In this case it's to rebroadcast it, but it could just save it to a file or whatever
[06:21:57 CEST] <k_sze_> Your nginx server is serving a stream or receiving a stream?
[06:22:07 CEST] <Max-P> Both
[06:22:33 CEST] <k_sze_> So you use ffmpeg to push a stream to the nginx server using rtmp.
[06:22:42 CEST] <Max-P> It receives it from me, dump it to a file and redistribute it to anyone connected to it.
[06:22:48 CEST] <k_sze_> interesting
[06:23:03 CEST] <Max-P> Ffmpeg may have one built-in, need to check
[06:23:12 CEST] <k_sze_> rtmp as in this, right? https://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol
[06:24:22 CEST] <Max-P> yes
[06:25:09 CEST] <Max-P> There's that for the client side (ffmpeg): https://trac.ffmpeg.org/wiki/StreamingGuide
[06:25:58 CEST] <Max-P> What do you want to do exactly? The computer that receives it, what does it do with it?
[06:26:34 CEST] <k_sze_> The computer that receives it is supposed to do some real-time machine vision on the stream.
[06:27:34 CEST] <Max-P> And how does that vision program work, you have to push a stream into it?
[06:28:01 CEST] <k_sze_> yes, that's it idea.
[06:29:41 CEST] <Max-P> Is it something that exists (and already listens somehow on a port and expects a specific format), or is it something you are making with the ffmpeg library?
[06:33:31 CEST] <Max-P> Also, just found it, it does support listening on both sides, so it works for ffmpeg to ffmpeg directly for sure. "Point to point streaming" in the wiki page I linked. rtp:// rtsp:// tcp:// udp:// all with the ?listen flag
[06:38:45 CEST] <k_sze_> something I'm going to make.
[06:39:05 CEST] <k_sze_> Which is why I would like to use some existing protocol if there is a suitable one.
[06:39:25 CEST] <k_sze_> nice
[06:41:51 CEST] <Max-P> So yeah, udp/tcp/rtp/rtsp/rtmp are all valid protocols, pick the one that fits the environment the best
[06:43:55 CEST] <k_sze_> There is no relationship between these protocols and container formats, right? So I encode the frame into packets, mux the packets into a container format, and use one of these protocols to stream the container?
[06:45:18 CEST] <Max-P> Yeah I think, I don't know how it works in the ffmpeg library
[07:19:03 CEST] <solrize> icecast?
[07:29:25 CEST] <zumba_addict> is my boss right that when video source has drm, the video has to be completely downloaded first before we can watch it?
[07:30:15 CEST] <Max-P> zumba_addict: no. Otherwise you'd have to download everything entirely on Netflix before you watch it ;)
[07:30:18 CEST] <ln-> not that i know anything, but i strongly doubt that's true for all kinds of videos and drm.
[07:30:33 CEST] <ln-> and indeed Netflix would have been my counter example :)
[07:30:40 CEST] <zumba_addict> ok
[07:30:59 CEST] <zumba_addict> now I need to make a case to prove that what he thinks is wrong
[07:31:11 CEST] <zumba_addict> or what he currently know is wrong
[07:31:37 CEST] <zumba_addict> but i need to present it in a nice way which won't make him feel, I'm stepping on his skills
[07:33:50 CEST] <Max-P> Ask him to find one example of DRM that requires to load the entire file to decode it
[07:34:31 CEST] <Max-P> Because I can't find one actually. Flash, silverlight, DVD, BluRay, ... none of them needs to read the entire thing to open
[07:35:07 CEST] <zumba_addict> k
[07:35:18 CEST] <Max-P> It doesn't make sense for this to even have been a thing at one point
[07:35:48 CEST] <zumba_addict> got it
[07:36:16 CEST] <Max-P> encryption/decryption has always been in a way that you only work on small chunks of data at a time, I don't know of any crypto algorithm that would work on the entire data at once
[07:36:33 CEST] <zumba_addict> do videos with DRM still have moov atom?
[07:36:36 CEST] <aldnavleech> how do you rescale a video into 16:9 aspect ratio, and put a black padding?
[07:37:29 CEST] <Max-P> aldnavleech: Why do you want to do that? Players usually add the black borders themselves
[07:37:30 CEST] <aldnavleech> i still cant seem to get it done
[07:38:09 CEST] <aldnavleech> Ah, I just want to do it during encoding
[07:38:18 CEST] <aldnavleech> especially avconv
[07:38:53 CEST] <Max-P> What's your problem, is it that the video appears stretched? Because adding useless black border usually just use space for no reason and make it annoying to display on different screens
[07:40:01 CEST] <Max-P> It made sense long ago to make VHS and DVDs because the format was fixed, but it doesn't make sense nowadays as any sane video player will auto fit it the best possible in the screen
[07:40:44 CEST] <aldnavleech> this is for web/mobile actually
[07:41:37 CEST] <aldnavleech> just like how youtube does to videos
[07:41:58 CEST] <Max-P> YouTube doesn't add black bars, they even specifically say not to in their guidelines
[07:41:59 CEST] <aldnavleech> i would want to do the same
[07:42:11 CEST] <aldnavleech> ah.
[07:42:14 CEST] <aldnavleech> thanks for the info
[07:42:18 CEST] <Max-P> It just transfers the actual video, and just fit it appropriately in the player
[07:42:32 CEST] <Max-P> And so does any of the popular mobile platforms
[07:43:00 CEST] <aldnavleech> "YouTube uses 16:9 aspect ratio players. If you are uploading a non-16:9 file, it will be processed and displayed correctly as well, with pillar boxes (black bars on the left and right) or letter boxes (black bars at the top and bottom) provided by the player. If you want to fit the player perfectly, encode at these resolutions:"
[07:43:21 CEST] <Max-P> Yes, but it's done on the client side
[07:43:23 CEST] <aldnavleech> https://support.google.com/youtube/answer/1722171?hl=en
[07:44:13 CEST] <Max-P> Yes, that's their recommendation so if you can, you record at that resolution
[07:44:48 CEST] <Max-P> If you don't, then you just give them the file in the correct resolution. You don't add the bars yourself
[07:45:45 CEST] <aldnavleech> but what if i want it in the encoding anyway? :)
[07:46:07 CEST] <Max-P> What you're asking is exactly against their recommendation
[07:46:46 CEST] <aldnavleech> its okay
[07:47:01 CEST] <Max-P> But if you really want to do it, you can use the "pad" video filter: http://superuser.com/questions/26416/how-to-convert-a-169-movie-to-a-43-let…
[07:47:04 CEST] <aldnavleech> let's ignore the youtube part
[07:48:12 CEST] <Max-P> But keep in mind it's a terrible idea. You don't want black bars in the final video file for any reason. It's wasting space and incredibly inconvenient if you suddently need a different aspect ratio
[07:49:17 CEST] <Max-P> As I said, any sane video players including mobile will play 4:3 videos on their 16:9 or 16:10 screen perfectly, they will add their own bars. It's a trivial calculation, you don't need to think about it
[08:06:14 CEST] <k_sze_> Why does AVFrame.best_effor_timestamp exist?
[08:10:09 CEST] <k_sze_> I mean, what's wrong with AVFrame.pkt_pts?
[08:11:30 CEST] <k_sze_> Is it because pkt_pts can be the same for multiple frames if the frames come from the same packet?
[08:11:59 CEST] <k_sze_> And so ffmpeg would interpolate a proper best_effort_timestamp for each frame?
[08:33:17 CEST] <mtcjayne> When I use ffmpeg my CPU usage climbs to 100%. Is there a way to use my video card for processing instead of my CPU, or is this something implementations of FFmpeg like VLC have to do?
[08:40:59 CEST] <k_sze_> mtcjayne: depends on the codec in question. Some codecs can benefit from hardware acceleration, others can't.
[08:41:43 CEST] <k_sze_> and so it depends on whether your copy of ffmpeg is built with the proper configuration, and whether the video in question is using one of those codecs that can benefit from hardware acceleration.
[08:41:44 CEST] <mtcjayne> I am using h264
[08:42:34 CEST] <k_sze_> h264 can benefit somewhat from hardware acceleration, especially if you have an NVidia video card and your ffmpeg has nvenc enabled.
[08:43:07 CEST] <k_sze_> For certain chroma subsamplings, it can also benefit from Intel QuickSync.
[08:44:48 CEST] <mtcjayne> I am using a Radeon R7 260X, and my build information is here: http://pastebin.com/2BcF5AqM
[08:45:41 CEST] <k_sze_> Radeon R7 should support OpenCL, so you should still be able to benefit from OpenCL for lookahead operations.
[08:46:26 CEST] <k_sze_> (I'm just regurgitating stuff I have read here and there about hardware acceleration in the past months. I'm no expert.)
[09:09:15 CEST] <mtcjayne> Hmm so since I'm rendering at about 50-100 FPS on a concat operation I can't improve that or reduce my CPU usage noticably
[09:15:28 CEST] <k_sze_> If I want to convert from one pixel format to another that is basically just a byte rearrangement (e.g. yuv422p to yuyv422), what flag should I supply to sws_getContext? SWS_BITEXACT?
[11:33:28 CEST] <thecoolguy> Is there a way to make mpeg-dash seekable ?
[12:02:12 CEST] <thecoolguy> anyone ?
[12:14:31 CEST] <jules> Hi, I'm currently playing with the ffmpeg C api. Is there a way to get the current bitrate on packet level?
[12:34:22 CEST] <thecoolguy> is there there a way to have ffmpeg encode to a fileformat that is playable over http while it is transcoding ?
[12:43:04 CEST] <DHE> HLS is probably the best option there, but there's quite a bit of latency introduced.
[12:50:07 CEST] <k_sze_> Hmm, I think I'm still getting *some* memory leak using ffmpeg.
[12:50:31 CEST] <k_sze_> I now make sure to av_free_packet, and that cut down most of leak.
[12:51:45 CEST] <k_sze_> Is there any other place where I can leak if all I'm doing is decode and convert pixel format?
[12:52:56 CEST] <thecoolguy> dhe
[12:53:15 CEST] <thecoolguy> i tried hls with nginx rtmp module but it only seems to support live streaming and not vod
[12:54:01 CEST] <DHE> oh... if the intention is VOD then HLS might be a good choice then. you said "while transcoding" which makes me think of live events only
[12:54:35 CEST] <DHE> it's worth a spin. whether you like it or not is another issue. it has its ups and downs
[13:15:46 CEST] <thecoolguy> DHE yea i know
[13:16:01 CEST] <thecoolguy> the thing is i want the hls to be seeakable
[13:16:19 CEST] <thecoolguy> and it doesn't seem like the rtmp module for nginx supports that
[13:42:19 CEST] <maksimka> ffmpeg keeps freezin on my machine any advice? http://pastebin.com/MqXK0Tpd
[13:55:58 CEST] <thecoolguy> is it possible to get ffmpeg to save to a mp4 chunk ever 10 seconds or something ?
[14:07:15 CEST] <DHE> thecoolguy: -hls_list_size X (where X should be 0 for content that's available start to end)
[14:08:51 CEST] <thecoolguy> I'm using -ac 6 -strict -2 -c:a aac -c:v libx264 -preset ultrafast -f mp4 segment -segment_times 10,20 -c copy -map 0 "test.mp4
[14:08:56 CEST] <thecoolguy> but it doesn't seem to be spliting the file at all
[14:09:45 CEST] <DHE> I think you want -f segment -segment_format mp4
[14:11:17 CEST] <thecoolguy> like this ? -f segment -segment_times 10,20 mp4
[14:12:12 CEST] <DHE> no
[14:13:54 CEST] <maksimka> any idea what I am doing wrong here? http://pastebin.com/MqXK0Tpd it keeps freezing ..
[14:14:31 CEST] <thecoolguy> exactly as you wrote it ?
[14:27:12 CEST] <thecoolguy> ?
[14:39:19 CEST] <maquefel> guys why i get too fast streaming from mjpeg file ? ffplay playes normal
[14:39:58 CEST] <maquefel> streaming with ffmpeg -vcodec mjpeg -f mjpeg -i 1.avi -codec mjpeg -r 25 http://localhost:8080/webcam.ffm
[14:41:00 CEST] <maquefel> ffserver settings :
[14:41:01 CEST] <maquefel> https://bpaste.net/show/a22ac5e3c9ac
[15:02:28 CEST] <thecoolguy> How do i fix Codec for stream 1 does not use global headers but container format requires global headers
[15:02:40 CEST] <thecoolguy> i'm doing -ac 6 -strict -2 -c:a aac -c:v libx264 -preset ultrafast -map 0 -c copy -f segment -segment_time 5 -reset_timestamps 1 out%02d.mp4
[15:46:46 CEST] <Polochon_street> Hi! I'm decoding songs into an array with this function (http://pastebin.archlinux.fr/1475441) but after that when I access elements in my array, I have randoms (not in every songs) Conditional jump or move depends on uninitialised value(s) with Valgrind
[15:47:01 CEST] <Polochon_street> could my decode function insert these values? Is it fatal?
[15:50:35 CEST] <Polochon_street> maybe the memcpy(index*song->nb_bytes_per_sample + beginning, decoded_frame->extended_data[0], data_size); is invalid, but I believe that if I obtained data_size by av_samples_get_buffer_size, it valid, isn't it?
[16:14:18 CEST] <gonza_> hi people someone can help me with one question i have an error in my code when i try to allocate an AVPicture to buffer with avpicture_layout
[16:14:40 CEST] <gonza_> i have an error in av_image_fill_linesizes+112
[16:32:06 CEST] <thecoolguy> anyone know the reason behing my global header issue ?
[16:44:21 CEST] <thecoolguy> -ac 6 -c:a aac -c:v libx264 -preset ultrafast -map 0 -flags:v +global_header -c copy -g 5 -f segment -segment_time 10 -reset_timestamps 1 mov%02d.mp4
[16:44:31 CEST] <thecoolguy> i tried force it and it still gives me that error
[17:22:42 CEST] <klaxa> thecoolguy: that -c copy looks incorrect
[17:25:23 CEST] <Golfgeo> Hi all
[17:25:46 CEST] <thecoolguy> hm
[17:26:45 CEST] <Golfgeo> I've been playing around with ffmpeg and need to set specific options of my webcam from the commandline command I use to start ffmpeg. It's a h264 stream I'm getting and I need to set h264 specific settings within the cam. Any pointers, tips or a good howto on this?
[17:30:02 CEST] <Golfgeo> Basicly I've got one issue left and that is to change the baseline profile to a high profile so I don't need the scaler to go from a 420 to 422 profile
[17:43:31 CEST] <thecoolguy> klexa any suggestions ?
[17:46:03 CEST] <Golfgeo> Oh just so you know, this is for the "wonderfull" c920 and it's 264 stream... Yea, got it working even to a v4l2 loopback
[17:48:56 CEST] <Golfgeo> it needs about a 3 ghz cpu core/thread to do the convertion. So that's the thing I'm going after with the other profile by not needing any convertion with the scaler
[17:52:51 CEST] <Golfgeo> Anyone?
[17:53:42 CEST] <c_14> What do you mean set options?
[17:53:51 CEST] <c_14> If you want to set options for the camera, use v4l2-ctl
[17:54:18 CEST] <Golfgeo> can they be embedded into the ffmpeg command?
[17:57:35 CEST] <c_14> You can try setting -standard or -input_format
[17:59:00 CEST] <Golfgeo> Am using input_format, but basicly I need to tell v4l2 to set a number of stream specific options in the cam itself
[17:59:29 CEST] <c_14> Then you're probably going to have to use v4l2-ctl
[18:00:07 CEST] <thecoolguy> c_14 I'm using -ac 6 -c:a aac -c:v libx264 -preset ultrafast -map 0 -c copy -g 5 -f segment -segment_time 10 -reset_timestamps 1 mov%02d.mp4
[18:00:25 CEST] <thecoolguy> and the files anre spliting fine and it is playable on my computer but for some reason it nots playable in ios
[18:01:02 CEST] <c_14> Try adding -pix_fmt yuv420p
[18:01:06 CEST] <Golfgeo> will have a look at the v4l2-ctl options I have, thanks mate
[18:01:50 CEST] <c_14> thecoolguy: or maybe -profile:v main
[18:01:57 CEST] <c_14> https://trac.ffmpeg.org/wiki/Encode/H.264#Compatibility
[18:02:46 CEST] <thecoolguy> I've trid -profile:v baseline -level 3.0 with the same results .
[18:03:04 CEST] <c_14> And the pix_fmt ?
[18:03:10 CEST] <thecoolguy> about to try that now
[18:06:51 CEST] <thecoolguy> yea still not playable. yet when i use certain inputs it is one sec let me get the codec info
[18:11:49 CEST] <thecoolguy> This out worked
[18:11:58 CEST] <thecoolguy> http://i.imgur.com/XtAoItS.png
[18:12:49 CEST] <thecoolguy> while this didn't http://i.imgur.com/fe5f6mR.png
[18:13:38 CEST] <thecoolguy> could it be that there are settings that are to high ?
[18:16:18 CEST] <c_14> hmm, could you provide the ffprobe output of those files? Can't really see anything interesting in that output.
[18:17:14 CEST] <thecoolguy> ok one sec
[18:18:52 CEST] <thecoolguy> any flags or just ffprobe file ?
[18:18:57 CEST] <c_14> just ffprobe file
[18:19:59 CEST] <thecoolguy> Working file http://pastie.org/private/luhkvdlqydwaete6mfkzag
[18:21:04 CEST] <thecoolguy> file broken on ios http://pastie.org/private/j3uhpcx4cawoioyvw2kw4a
[18:23:40 CEST] <c_14> Maybe the audio or subtitle track?
[18:23:47 CEST] <c_14> That or one of the metadata tags
[18:28:08 CEST] <thecoolguy> hm how to a speicify to remove the audio and ubstile chanel using flags ?
[18:28:17 CEST] <thecoolguy> how do i*
[18:29:52 CEST] <c_14> Either explicitly map the video track or use -an -sn
[18:32:24 CEST] <w33t_> howdy! we are trying to compile ffmpeg for ios and we are getting an error saying that librtmp isnt found.
[18:32:38 CEST] <w33t_> we are working off of this: https://github.com/chrisballinger/FFmpeg-iOS
[18:33:02 CEST] <w33t_> it directed us to this room in the build script lol
[18:34:24 CEST] <c_14> Do you need librtmp?
[18:37:01 CEST] <thecoolguy> tried "-an -sn -map_metadata" and still doesn't work. Is there a flag to recalculate duration ?
[18:37:35 CEST] <c_14> hmm?
[18:39:21 CEST] <thecoolguy> Thats the only thing i can think of even after remove the audio, subtitle , and metadata it isn't playing
[18:39:37 CEST] <thecoolguy> the prob is this now http://pastie.org/private/n1jtczeo9agzctnlgglca
[18:40:10 CEST] <thecoolguy> thats pretty much the same as the working example except the duration is wrong
[18:40:29 CEST] <thecoolguy> o wait no it is right
[18:41:12 CEST] <thecoolguy> see any important differences ? they look exactly the same to me
[18:41:34 CEST] <thecoolguy> wel besides bitrate and duration
[18:42:03 CEST] Action: c_14 doesn't notice anything besides resolution and fps
[18:42:09 CEST] <thecoolguy> makes no sense x.x
[19:39:46 CEST] <NapoleonWils0n> hello all
[19:40:09 CEST] <NapoleonWils0n> can ffmpeg use an http proxy ?
[19:40:29 CEST] <NapoleonWils0n> thought i saw something about setting http_proxy somewhere
[19:40:47 CEST] <c_14> There's the httpproxy protocol
[19:41:44 CEST] <NapoleonWils0n> c_14 so can you set http_proxy=something and ffmpeg will use that proxy
[19:42:14 CEST] <DHE> well, you can specify one that way, but c_14 meant there's an input format called "httpproxy" like you have a format for "mp4"
[19:42:25 CEST] <DHE> okay, that's not quite right...
[19:43:23 CEST] <NapoleonWils0n> DHE right so you can get ffmpeg to use an http proxy by setting an env variable for http_proxy is that right
[19:43:27 CEST] <c_14> Not sure how the httpproxy protocol is supposed to be used, but it looks like there is support for the http_proxy environment variable
[19:45:57 CEST] <NapoleonWils0n> any ideas how to set that on linux
[19:46:14 CEST] <NapoleonWils0n> env http_proxy="http://127.0.0.1:6883"
[19:46:42 CEST] <c_14> export http_proxy="http://127.0.0.1:6883"
[19:47:04 CEST] <NapoleonWils0n> right will give it a go
[19:47:37 CEST] <NapoleonWils0n> does ffmpeg pick that up automatically or do i need to pass another argument to ffmpeg
[19:48:48 CEST] <c_14> picks it up automatically
[19:52:14 CEST] <NapoleonWils0n> c_14 i think i love you mate
[19:52:20 CEST] <NapoleonWils0n> just got it working
[19:52:59 CEST] <NapoleonWils0n> actually very cool this works
[19:54:00 CEST] <NapoleonWils0n> just worked out how to record nbc sports with ffmpeg using tinyproxy and adding x-forward header
[20:48:31 CEST] <Guest49918> hi
[20:48:53 CEST] <jwp> i have a question about ffprobe and metadata extraction
[20:49:02 CEST] <jwpppppp> when using ffprobe for metadata extraction, why are properties like "duration", "start_time", "sample_rate" represented as strings when specifying JSON as output?
[20:53:25 CEST] <ChocolateArmpits> eh, What else should they be ?
[20:55:34 CEST] <jwpppppp> ChocolateArmpits: duration and start_time should be a JSON number (float representation) and sample_rate also a JSON number but with integer representation
[20:55:38 CEST] <jwpppppp> maybe I'm missing something?
[20:56:07 CEST] <jwpppppp> e.g. "width" and "height" are JSON numbers (integers) on the JSON output
[21:10:19 CEST] <luc4_> Hello! Is there a list of the accepted params for cpu in configure?
[21:10:30 CEST] <luc4_> I meant accepted values sorry.
[21:39:23 CEST] <claz> is there any way ( using filters or similar ) to add a single frame to the beginning of the video stream?
[21:39:43 CEST] <claz> i have a lot of segments from the same camera that I want to use vidstab on
[21:40:19 CEST] <claz> and i need to use vidstab in 'tripod' mode so it takes an input frame of the video which it uses to offset the entire video
[21:40:37 CEST] <claz> but if i use the first frame of each segment then every segment will be a little different..
[21:41:28 CEST] <ChocolateArmpits> luc4_: most likely not, most systems even when they have matching hardware might have different software running at a single time. There can only be broad generalizations, nothing concrete suggested
[21:42:22 CEST] <pzich> claz: you might be able to use this, but I don't know how well it works when your input is a single frame: https://trac.ffmpeg.org/wiki/Concatenate
[21:43:01 CEST] <claz> thanks, i'm going to try it
[21:44:03 CEST] <luc4_> ChocolateArmpits: I dont understand sorry. You mean I cannot know what to place there for a specific hardware?
[21:44:12 CEST] <pzich> claz: also, make sure to note that there are two sections, "Concatenation of files with same codecs" and "Concatenation of files with different codecs", you may be able to encode your image as a single-frame video of the same codec, or you may have to follow the second part
[21:44:52 CEST] <ChocolateArmpits> luc4_: There is no suggestion list for specific hardware and software setup
[21:45:30 CEST] <luc4_> ChocolateArmpits: if I dont put it it seems to work anyway& should I just not add it then?
[21:45:47 CEST] <ChocolateArmpits> luc4_: What do you mean by "it" ?
[21:46:03 CEST] <luc4_> ChocolateArmpits: - - cpu switch
[21:46:55 CEST] <luc4_> ChocolateArmpits: the proper CFLAGS are sufficient?
[21:48:09 CEST] <ChocolateArmpits> luc4_: What codec are you using ? I'm not finding the 'cpu' switch in ffmpeg's documentation . The cflags is told to only be used for testing.
[21:49:07 CEST] <luc4_> ChocolateArmpits: codec? Sorry& maybe I was not clear. Im building ffmpeg libs for arm. That switch is in the configure script docs.
[21:49:29 CEST] <luc4_> ChocolateArmpits: just run ./configure help and youll get it.
[21:49:39 CEST] <ChocolateArmpits> luc4_: ok, I got confused, I was thinking you were trying to run ffmpeg
[21:49:49 CEST] <luc4_> ChocolateArmpits: no no, building the libs.
[21:50:22 CEST] <luc4_> ChocolateArmpits: just wanted to know cause Ive seen that set in some cases& but not sure what the relationship is to march for instance.
[21:50:32 CEST] <luc4_> Probably more optimization?
[21:51:25 CEST] <llogan> yuo can view fate.ffmpeg.org and look at the various arm builds to see some configure examples. keep in mind that many are configured for fate testing, so for example you wouldn't need --enable-memory-poisoning --enable-avresample
[21:59:45 CEST] <Polochon_street> is avcodec_close(context) enough to prevent memory leaks from allocated codeccontext/codec?
[22:06:22 CEST] <llogan> Polochon_street: might want to ask libav-user mailing list. the mailing list for the FFmpeg libraries
[22:07:55 CEST] <Polochon_street> llogan: don't want to bother a whole mailing for this question, but thanks :)
[22:08:40 CEST] <Polochon_street> +I
[22:09:47 CEST] <llogan> that's what it is there for and it's not nearly as high volume as the others.
[22:10:23 CEST] <Polochon_street> okay, I'll do it then. Thanks!
[22:13:50 CEST] <claz> pzich: that works ! however the problem remains that each first frame of each segment is wrong, any way to remove it without transcoding?
[23:21:26 CEST] <CraziFuzzy> Does anyone know a way to have ffmpeg write to a circular buffer file? Some way to set a filesize, and it starts writing at the beginning, then when it reaches the end it continues overwriting from the beginning again?
[23:21:43 CEST] <CraziFuzzy> This would be an mpegts stream in the circular buffer.
[23:22:57 CEST] <DHE> there is the "segment" format, or a special case to use "hls" which has some additional baggage (.m3u8 file)
[23:23:31 CEST] <DHE> it writes to multiple files instead, but they concatenate to produce a fine usable video. use -hls_flags delete_segments as well
[23:24:03 CEST] <DHE> oh, segment supports wrapping. even better
[23:34:46 CEST] <CraziFuzzy> I had seen segment, and honestly, never even thought it would support wrapping. that sounds pretty much exactly what I'm looking for.
[23:37:55 CEST] <CraziFuzzy> so it looks like using a streamsegment format with a wrap limit of 1 might do what i want.
[23:38:51 CEST] <CraziFuzzy> actually, it looks like the segment size is based on duration, not filesize, so it won't really work for my purposes.
[00:00:00 CEST] --- Fri Aug 28 2015
1
0
[00:06:44 CEST] <philipl> getting mpv building isn't hard, and it's actually usable as a player
[00:09:30 CEST] <nevcairiel> another "useful" carl patch in that ticket =p
[00:10:31 CEST] <wm4> so where the heck are the kodi devs
[00:10:40 CEST] <nevcairiel> they probably dont care
[00:13:35 CEST] <nevcairiel> wth is with the indenation in matroskaenc.c, that part of the code is practically unreadable
[00:13:40 CEST] <nevcairiel> indentation*
[00:14:04 CEST] <nevcairiel> i hate it when people re-shuffle code and then someone says "dont reindent, makes it harder to read"
[00:14:09 CEST] <nevcairiel> yeah well the end result is crap
[00:14:50 CEST] <wm4> isn't the convention to including the reindentation in the final patch, or add it as separate commit?
[00:16:34 CEST] <Zerowalker> Is it possible to have a closed source plugin linked to ffmpeg?
[00:18:00 CEST] <Timothy_Gu> Zerowalker: no
[00:18:55 CEST] <nevcairiel> sure it is, use dynamic linking, build ffmpeg as LGPL
[00:19:06 CEST] <philipl> Or don't distribute the resulting binary.
[00:20:57 CEST] <Zerowalker> the plugin/patch would be that a closed sourced codec get's implemented into ffmpeg through dynamic lib or something. A private build
[00:21:23 CEST] <Zerowalker> i am not the one doing this the developing, but i am trying to find out if licensing allows this (and i suck at this license stuff)
[00:21:31 CEST] <kierank> you can't distribute that ffmpeg
[00:22:01 CEST] <Zerowalker> that's ok i think, as it's only intended for personal use
[00:22:35 CEST] <Timothy_Gu> Zerowalker: it's not legal to distribute this build, but if you are not distributing then I guess nobody cares
[00:22:57 CEST] <Zerowalker> but it's acceptable then? I download ffmpeg for example, then i patch it with the closed source so it links to a dynamic lib and a new codec appears
[00:23:18 CEST] <Zerowalker> but, it doesn't violate anything then, as long as it's not distributed?
[00:23:32 CEST] <Zerowalker> and i guess that means publication of sort
[00:25:10 CEST] <kierank> it means giving the binary to anyone
[00:28:15 CEST] <Zerowalker> i see, but the developer can make a patch and "distribute" that to who he wants, and then those that have it can privately compile an ffmpeg version with that patch, for private use?
[00:29:01 CEST] <kierank> yes but all those ffmpeg builds would be nonfree
[00:29:30 CEST] <j-b> Anyone started working on VC-5?
[00:29:57 CEST] <nevcairiel> wm4: reading the code, i'm suspicious that matroskaenc might write wrong values for those subtitle cue elements, though
[00:30:09 CEST] <Zerowalker> nonfree, you mean that in the sense that it can't be distributed for free cause of the other licenses? If so that's not a problem for private use:)
[00:30:25 CEST] <nevcairiel> j-b: do we have vc-2 through 4 done already? :d
[00:30:34 CEST] <j-b> nevcairiel: don't we?
[00:30:47 CEST] <j-b> nevcairiel: I thought we had vc-1-3
[00:30:49 CEST] <Zerowalker> But as long as that's allowed, and making a patch, codec thing in closed source etc, then i think i have it's all good
[00:31:08 CEST] <j-b> VC-2 is Diract and VC-3 is DNxHD
[00:31:46 CEST] <j-b> nevcairiel: VC-5 is Cineform
[00:36:28 CEST] <nevcairiel> vc-1 support is still not 100%, afaik dirac suffers a similar fate
[00:36:33 CEST] <wm4> nevcairiel: I haven't really checked yet (that's why I want the kodi devs to do that)
[00:36:45 CEST] <j-b> nevcairiel: indeed.
[00:36:51 CEST] <wm4> nevcairiel: from a superficial look it looked ok though
[00:37:03 CEST] <nevcairiel> i would be somewhat surprised if kodi actually uses the subtitle cues for subtitles on seek
[00:37:09 CEST] <nevcairiel> they probably just get confused by all the extra cues
[00:37:27 CEST] <wm4> (I thought kodi used ffmpeg's demuxer)
[00:37:41 CEST] <nevcairiel> no clue how that one behaves when seeking in such a stream
[00:37:43 CEST] <nevcairiel> i dont use it
[00:37:43 CEST] <nevcairiel> :D
[00:37:59 CEST] <nevcairiel> .. and i had to fix mine when these cues appeared
[00:41:14 CEST] <nevcairiel> anyway i think the cluster position in the cue thingy may be wrong
[00:41:23 CEST] <nevcairiel> but its getting late, and i will delay checking until tomorrow
[00:43:19 CEST] <wm4> you mean the "relative" cluster position?
[00:43:55 CEST] <nevcairiel> yeah
[00:44:07 CEST] <nevcairiel> from a quick look at the code, its relative to the start of the file, not the segment
[00:44:15 CEST] <nevcairiel> but maybe i missed something
[00:44:33 CEST] <philipl> wm4: on the subject of demuxing mkv, why doesn't mpv use the ffmpeg demuxer?
[00:44:53 CEST] <wm4> philipl: apparently ordered chapters are the main reason
[00:45:22 CEST] <wm4> (probably the same reason nevcairiel uses the haali code for mkv)
[00:45:28 CEST] <nevcairiel> bad seeking and ordered chapters/linked segments, yea
[00:45:40 CEST] <philipl> no one wants to push that to ffmpeg?
[00:46:13 CEST] <philipl> seems like no-one uses the demuxer in the real world right now.
[00:46:20 CEST] <nevcairiel> there would be a two year debate on which level to handle it, and in the end it would result in both of us having to rewrite mkv support
[00:47:18 CEST] <wm4> just exporting the ordered chapter info somehow would be enough for mpv, but yeah
[00:47:52 CEST] <philipl> *sigh*
[00:48:25 CEST] <wm4> actually a Libav dev had plans for this
[00:48:49 CEST] <wm4> exporting OC info as some sort of playlist, and avconv.c would have been able to use this info
[00:49:01 CEST] <philipl> That's probably the least controversial way to do it
[00:49:31 CEST] <wm4> there's a WIP branch somewhere (if it even still exists...)
[00:51:20 CEST] <nevcairiel> its like from 2011 and even that attempt was very controversial back then :p
[00:52:49 CEST] <wm4> wow 2011
[00:53:10 CEST] <wm4> and then there's the even older patch that implemented OC directly in the demuxer (haali-style)
[01:09:13 CEST] <cone-136> ffmpeg 03Timothy Gu 07master:0c6a92a447b3: matroskaenc: Fix indentation
[01:11:09 CEST] <Zerowalker> Is there a better place to discuss this licensing thing i asked about?
[01:11:34 CEST] <BtbN> turns out libva git already has the missing trace parameter stuff i just added myself to the release version...
[01:13:04 CEST] <wm4> BtbN: d'oh
[01:13:23 CEST] <BtbN> And libva git also plays 4K60 just fine
[01:13:27 CEST] <BtbN> hevc
[01:14:04 CEST] <wm4> you mean just changing to git made it work?
[01:15:22 CEST] <BtbN> yes, from libva/intel-driver 1.6.0 to latest git master.
[01:16:56 CEST] <llogan> Zerowalker: yes, ffmpeg-user since it's not about development of FFmpeg
[01:17:19 CEST] <wm4> BtbN: sounds like very good news
[01:17:39 CEST] <BtbN> There is still this one sample with messed up colors
[01:17:52 CEST] <BtbN> And i can't figure out if it's just broken or there's something wrong with the code
[01:18:14 CEST] <BtbN> ffplay playing it flawlessly suggests it's something in the code
[01:18:29 CEST] <BtbN> gst is refusing to play it at all, because invalid format
[01:19:08 CEST] <Compn> BBB : i'm registered and coming already
[01:19:23 CEST] <Compn> BBB : actually i'm going to be in france driving around from sept 5-22 ...
[01:19:49 CEST] <Compn> although i barely speak 5 words of french
[01:20:51 CEST] <Compn> so also i'm not going to be on irc.
[01:21:05 CEST] <Compn> llogan : do you mind taking over doing ml moderation?
[01:21:22 CEST] <Compn> (not that i've been helping much)
[01:22:02 CEST] <llogan> sure, but i didn't know anyone else was doing it.
[01:22:30 CEST] <Compn> i've been doing it off and on for few years now :P
[01:23:26 CEST] <llogan> i guess it was you then who does the mystery queue clearing i see once in a great while
[01:24:03 CEST] <Compn> it gets cleared but fills back up again quickly :P
[01:24:20 CEST] <durandal_1707> want vc-5? Pay!
[01:24:32 CEST] <Compn> (i also do mplayers' moderation, rarely)
[01:25:17 CEST] <Compn> BBB : i'm trying to remember if we met at vdd in paris or dublin
[01:25:31 CEST] <BBB> I was in paris for 15 minutes a few years back
[01:25:40 CEST] <BBB> I was traveling to the netherlands and happened to be in town
[01:25:40 CEST] <Compn> i've got the long beard
[01:25:42 CEST] <Compn> ah
[01:25:47 CEST] <BBB> but I was only there for 15 minutes and then had to run
[01:25:48 CEST] <BBB> sadly
[01:25:51 CEST] <BBB> this time Il be there the whole time
[01:27:32 CEST] <Compn> for disneyland too ? :P
[01:27:37 CEST] <Compn> on the 18th
[01:29:35 CEST] Action: Compn afk
[01:29:54 CEST] <Compn> nevcairiel : dont worry, i wont be joining in the ffmpeg/libav talks...
[01:33:52 CEST] <philipl> BtbN: might be a libva bug of course.
[01:34:03 CEST] <philipl> I've got some vdpau brokenness that I'm pretty sure is a driver/library issue
[01:34:28 CEST] <philipl> can you remux the file to make gst happy?
[01:34:29 CEST] <BtbN> gst not playing the file at all is not exactly helpfull to determine if some of my parameters are wrong
[01:34:34 CEST] <philipl> or does it think the stream is broken?
[01:34:44 CEST] <BtbN> It complains about it way after the demuxer level
[01:34:51 CEST] <BtbN> vaapidecode says the picture is invalid
[01:35:02 CEST] <philipl> And in your code it doesn't?
[01:35:11 CEST] <philipl> Might be worth seeing where it's barfing in gst and if you can fix it...
[01:35:18 CEST] <BtbN> I'm not using gst modules in my ffmpeg code ;)
[01:35:36 CEST] <philipl> I mean compile all of gst from scratch and get to work :-)
[01:36:31 CEST] <philipl> My 'reference' application was the hacked up nvidia app that borrowed a ton of code from gst but displayed frames in decode order.
[01:36:35 CEST] <philipl> Made it hard to spot visual problems...
[01:51:34 CEST] <cone-136> ffmpeg 03Timothy Gu 07master:b144008c1ba6: ffmpeg_opt: Add missing comma
[02:20:16 CEST] <BtbN> philipl, "GstVaapiDecode:vaapidecode0: No valid frames decoded before end of stream"
[02:20:20 CEST] <BtbN> Is the error gst gives
[02:30:20 CEST] <BtbN> according to the va trace log, it doesn't even try to decode a single frame
[02:30:33 CEST] <BtbN> so i guess their nevc parser dislikes what it sees
[02:30:37 CEST] <BtbN> *hevc
[02:41:09 CEST] <cone-136> ffmpeg 03Timothy Gu 07master:68a9c8ac774d: swscale: Silence an unused variable warning
[04:02:55 CEST] <cone-136> ffmpeg 03Michael Niedermayer 07master:dda69253578f: avformat/segment: Do not free the filename twice
[05:00:47 CEST] <cone-136> ffmpeg 03James Almer 07master:4c39892b6741: avcodec/vdpau: fix compilation of mpeg1/mpeg4/vc1 decoders when h264 is disabled
[05:10:08 CEST] <philipl> BtbN: weird.
[05:10:27 CEST] <philipl> That's the gst parser giving up, not anything in libva right?
[09:23:32 CEST] <j-b> Daemon404: it's called LibreOfficeKit and they are consolidating it.
[10:43:24 CEST] <cone-136> ffmpeg 03Paul B Mahol 07master:e030d3c61fdb: avfilter/vf_blend: use the name 's' for the pointer to the private context
[10:52:45 CEST] <BtbN> philipl, yes. libva is initialized, but nothing is ever decoded with it. It gives up before. But in the vaapidecode module. So it can only be the nal parsing happening there.
[10:53:59 CEST] <BtbN> http://forum.kodi.tv/showthread.php?tid=231955&pid=2089922#pid2089922 has some more samples that are broken in similar ways though
[10:55:44 CEST] <BtbN> So i'll assume something is still slightly broken.
[11:50:11 CEST] <cone-136> ffmpeg 03Paul B Mahol 07master:47df8716451f: avfilter/af_aphaser: use the name 's' for the pointer to the private context
[12:03:36 CEST] <durandal_1707> Why is there libavfilter/log2_tab.c?
[12:16:52 CEST] <cone-136> ffmpeg 03Ganesh Ajjanagadde 07master:6455e4fb5bc3: configure: do not fork off grep subprocess while testing for whitespace
[13:07:49 CEST] <BtbN> __gb__, if you have some time, i posted the vaapi hevc patch on ffmpeg-devel.
[13:11:38 CEST] <cone-136> ffmpeg 03Paul B Mahol 07master:3fbc9deb954c: avfilter/vf_vectorscope: fix bug in checking pixel format flags
[13:11:39 CEST] <cone-136> ffmpeg 03Paul B Mahol 07master:a16251a6d040: avfilter/vf_histogram: fix bug in checking pixel format flags
[13:15:46 CEST] <BtbN> __gb__, also, I found some samples that have distorted colors when played via ffmpeg. gst refuses to play them at all, with a strange error from vaapidecode
[13:16:27 CEST] <BtbN> https://dl.dropboxusercontent.com/u/46848344/hevc/birds_1080p_24fps_h265.mkv for example
[13:27:16 CEST] <nevcairiel> I wouldn't get distracted by the gst failure, its probably a red herring
[13:27:27 CEST] <nevcairiel> the sample decodes fine with other hardware interfaces
[13:28:45 CEST] <BtbN> Well, but without gst decoding it correctly i have nothing to compare the trace against. :D
[13:29:27 CEST] <nevcairiel> you could debug gst and see where it fails
[13:29:50 CEST] <BtbN> Just setting all the delta luma/chroma weight/offset parameters to 0 yields better results, but it still shows artifacts on those samples
[13:29:52 CEST] <nevcairiel> maybe remux to ts or raw h265 to see if it changes anything
[13:30:09 CEST] <BtbN> The vaapidecode module fails at parsing the bitstream
[13:30:14 CEST] <BtbN> remuxing has no effect
[13:30:25 CEST] <BtbN> It doesn't even reach libva
[13:31:19 CEST] <BtbN> Which makes me suspect that there is some hevc corner case that wasn't respected when implementing gst(and maybe even libva)
[13:32:06 CEST] <BtbN> The only other reason i can still think of is that the luma/chroma offsets are wrong, and the calculation ffmpeg does on them doesn't match what libva expects
[13:32:36 CEST] <nevcairiel> the chroma offsets are only read if chroma_weight_l0_flag[i] is set
[13:32:45 CEST] <nevcairiel> but you never see those flags
[13:32:58 CEST] <nevcairiel> but if they are not set, it should zero the struct .. hm
[13:33:13 CEST] <BtbN> That flag doesn't exist.
[13:33:18 CEST] <BtbN> in the libva interface
[13:33:56 CEST] <nevcairiel> if its not set in the bitstream, it would result in avcodec nulling out the weight and offsets anyway
[13:34:07 CEST] <BtbN> The values are propperly zeroed though, that's visible in the trace logs
[13:34:09 CEST] <nevcairiel> and 0 seems to be the proper fallback value to set it to
[13:34:45 CEST] <BtbN> There are only errors on frames where they are not 0
[13:34:58 CEST] <Daemon404> j-b, oh. glob help us all.
[13:41:48 CEST] <nevcairiel> I bet your scaling lists are still wrong, since you dont un-zigzag them
[13:42:04 CEST] <nevcairiel> but that should cause general corruption, not necessarily colors being wrong
[13:54:32 CEST] <BtbN> nevcairiel, found something else: slice_param->delta_chroma_log2_weight_denom = sh->chroma_log2_weight_denom;
[13:54:36 CEST] <BtbN> ffmpeg un-delta'd it
[13:54:48 CEST] <BtbN> s->sh.chroma_log2_weight_denom = av_clip_uintp2(s->sh.luma_log2_weight_denom + delta, 3);
[13:54:53 CEST] <BtbN> and that doesn't look exactly reversible
[13:55:14 CEST] <soummyaah> Hey! I'm new to the ffmpeg community. I wanted to know if you would be participating in the September round of internships via Outreachy. Also, how could I start contributing? (Whether you are going to be participating or not.) I've read a bit about ffmpeg and the work done here excites me. Though it all seems very new to me. What would be the best way to proceed?
[13:55:47 CEST] <wm4> soummyaah: subscribe to the development mailing list, and watch how things work
[13:56:28 CEST] <wm4> then you could look at the bug tracker and attempt to analyzer and fix issues
[13:56:33 CEST] <wm4> *analyze
[13:56:38 CEST] <soummyaah> wm4 Thanks for the advice. Are there any easy open issues I could get started with?
[13:56:45 CEST] <wm4> (I don't know about the Outreachy process)
[13:57:14 CEST] <wm4> I don't know... you'll pretty much have to look yourself
[13:57:17 CEST] <soummyaah> Sounds good. Could I PM you in case I need to ask more?
[13:57:32 CEST] <wm4> just ask on this channel, I'm not anyone special either
[13:57:59 CEST] <soummyaah> Okay, thanks! I'll start with the mailing list and the bug tracker.
[13:59:05 CEST] <wm4> at first you'll probably want to find out how to use git, how to compile ffmpeg, how to run our test suite FATE (if you didn't already)
[14:01:57 CEST] <soummyaah> I've familiar with git and have compiled ffmpeg. I haven't run the test suite yet though. I'll start with that.
[14:08:21 CEST] <wm4> excellent... doc/fate.texi has more information
[14:10:23 CEST] <wm4> is the "old" bug tracker available anywhere? I'm looking at a commit from 2008, and it references an issue number which obviously doesn't match with our current bug tracker
[14:12:53 CEST] <nevcairiel> BtbN: the clipping shouldnt trigger in a conformant stream, so just subtract the luma value?
[14:13:11 CEST] <BtbN> yeah, i just noticed that it doesn't clip it to 3, but to 1 << 3
[14:16:55 CEST] <nevcairiel> does it help?
[14:18:28 CEST] <BtbN> Found some other stuff gst does diffrently, adding that right now.
[14:19:18 CEST] <BtbN> https://github.com/gbeauchesne/gstreamer-vaapi/blob/master/gst-libs/gst/vaa… seems strange, isn't the value only set when chroma_format_idc != 0? So the logic is reversed here?
[14:19:58 CEST] <nevcairiel> the ffmpeg condition says != 0
[14:22:18 CEST] <wm4> yeah, why does vf_colormatrix exist at all
[14:22:59 CEST] <wm4> in the libavfilter model all video conversions happen with vf_scale, so why have additional filters which take care of such aspects
[14:23:06 CEST] <nevcairiel> obviously the answer is because swscale cant do the job
[14:23:17 CEST] <wm4> yeah, too hard to fix libswscale
[14:23:21 CEST] <nevcairiel> vf_scale is a scale filter, a pure yuv conversion doesnt really fit the bill
[14:23:31 CEST] <wm4> sure it does
[14:23:42 CEST] <wm4> the API even supports it, as far as I can see
[14:23:53 CEST] <nevcairiel> you would need a dedicated processing path for this
[14:23:57 CEST] <nevcairiel> ie. copy colormatrix =p
[14:28:28 CEST] <BtbN> nevcairiel, so far no sample i tested even used the sacling lists, so they might very well be wrong, yes.
[14:29:04 CEST] <nevcairiel> fate has a few
[14:29:45 CEST] <nevcairiel> if only i remembered which
[14:30:00 CEST] <nevcairiel> SLIST_* are probably a good bet =p
[14:33:08 CEST] <BtbN> Are you looking at http://samples.ffmpeg.org/allsamples.txt ?
[14:33:28 CEST] <nevcairiel> nah fahttp://fate-suite.ffmpeg.org/hevc-conformance/
[14:33:32 CEST] <nevcairiel> woops
[14:33:34 CEST] <nevcairiel> http://fate-suite.ffmpeg.org/hevc-conformance/
[14:34:13 CEST] <nevcairiel> the SLIST samples is what I used to figure out scaling list problems
[14:34:37 CEST] <nevcairiel> or you know, just copy vdpau or dxva2
[14:35:47 CEST] <BtbN> the birds sample is fixed now.
[14:35:59 CEST] <BtbN> propably just the missing delta
[14:36:48 CEST] <nevcairiel> yay
[14:37:21 CEST] <BtbN> The SLIST ones definitely are still broken
[14:48:36 CEST] <BtbN> strange stuff
[14:48:45 CEST] <BtbN> luckily the code from vdpau just works
[16:12:20 CEST] <nevcairiel> So we actually respond to his issue and we're the bad guys now, instead kodi flst out ignored him, and they are perfect
[16:12:27 CEST] <nevcairiel> Some guys sure are jaded :p
[16:13:30 CEST] <wm4> from a superficial look at our code, I feel like I should push a reindent commit
[16:13:40 CEST] <wm4> from a second look, it seems like the code is correct
[16:14:02 CEST] <wm4> the relative position thing, I mean
[16:14:10 CEST] <wm4> relative_packet_pos = avio_tell(s->pb) - mkv->cluster.pos;
[16:14:33 CEST] <nevcairiel> Yeah I found the missing piece, it seems fine
[16:14:40 CEST] <wm4> I also remember how support for this got added, and I explicitly tested it (and I've already found out before that mkvmerge wrote this incorrectly, and got mkvmerge to fix their bug)
[16:14:56 CEST] <nevcairiel> The only issue is the order of the cues, apparently
[16:15:09 CEST] <wm4> and I agree that the order isn't guaranteed
[16:15:49 CEST] <nevcairiel> But the order would be a more fundamental problem in avformat mixing code
[16:15:55 CEST] <nevcairiel> Muxing*
[16:17:08 CEST] <BtbN> Even with correct(?) ScalingList handling, the samples still show artifacts.
[16:17:16 CEST] <BtbN> gst shows the exact same ones though
[16:43:43 CEST] <wm4> "I am disappointed that the Kodi devs haven't addressed it, but I know the person who usually takes care of it (FernetMenta?) is busy implementing hevc acceleration via vaapi in, strangely enough, FFmpeg. "
[16:45:24 CEST] <nevcairiel> too bad his work is all for nothing :p
[16:47:33 CEST] <wm4> I wonder what "AV sync issue in stream 1 at 0:00:13.823 with duration of 0.666ms : broken timecode, apparent audio skew is -1ms" is about
[16:47:47 CEST] <wm4> isn't this natural, since matroska timestamps are usually rounded to milliseconds?
[16:48:23 CEST] <wm4> and since matroska doesn't have fractional timestamps, it can't be fixed
[16:50:00 CEST] <nevcairiel> he collected like 3 different "symptoms" of some errors in that report by now, its just nonsensical raving of a user
[16:51:15 CEST] <nevcairiel> BtbN: if it decodes things equal to gst now, i would say just ship it and fix whatever needs fixing later, it looks fine to me so far
[16:52:37 CEST] <nevcairiel> i think we hurt his feelings now, and we didnt even get mean
[16:52:44 CEST] <wm4> *shrug*
[16:54:46 CEST] <nevcairiel> i still bet the mere presence of the subtitle cues causes it, or something
[16:55:08 CEST] <nevcairiel> the ffmpeg mkv demuxer seek method seems to somehow try to do something with subtitle cues
[16:55:15 CEST] <nevcairiel> but seeking was always a bit flaky in that one
[16:55:34 CEST] <nevcairiel> he even in one post said remuxing with mkvmerge didnt help
[16:55:42 CEST] <nevcairiel> makemkv probably just doesnt wr ite subtitle cues
[16:56:04 CEST] <philipl> BtbN: So, either you've faithfully reproduced an error in the gst impl, or it's a low level bug :-)
[16:56:24 CEST] <philipl> But if you can get gst to show it in a broken way, then I think __gb__ might feel obliged to fix it.
[16:58:51 CEST] <BtbN> just the 4 SLIST_* samples from fate
[16:58:55 CEST] <BtbN> ffplay plays them correctly
[16:59:01 CEST] <BtbN> gst and mpv/kodi don't.
[16:59:07 CEST] <BtbN> via vaapi
[16:59:15 CEST] <philipl> Weird.
[16:59:28 CEST] <wm4> BtbN: ffplay has vaapi support?
[16:59:31 CEST] <philipl> But that ought to be enough to make __gb__ reappear.
[16:59:50 CEST] <BtbN> No, otherwise it would propably also break in the same way.
[16:59:55 CEST] <nevcairiel> wm4: he meant software decoded
[17:00:00 CEST] <BtbN> I use ffplay to verify if the file works in general.
[17:00:16 CEST] <philipl> Well, I know the SLIST samples work in vdpau.
[17:00:18 CEST] <BtbN> Doesn't work too amazing for 4K stuff though
[17:00:28 CEST] <BtbN> yeah, they are definitely not broken
[17:00:31 CEST] <BtbN> it's something with vaapi
[17:01:37 CEST] <wm4> considering not even gst can do it, maybe you don't need to care yet
[17:01:50 CEST] <philipl> that's my thought.
[17:02:07 CEST] <wm4> the gst implementation is from an intel dev, isn't it
[17:02:19 CEST] <philipl> __gb__: :-)
[17:02:20 CEST] <BtbN> yes, from gb
[17:02:38 CEST] <BtbN> There are 3 parameters still marked as fixme/todo. In both ffmpeg and gs
[17:02:40 CEST] <BtbN> *gst
[17:02:43 CEST] <BtbN> maybe it's related to one of them
[17:02:53 CEST] <philipl> BtbN: Does LTRPSPS_A_Qualcomm_1.bit play correctly for you?
[17:03:14 CEST] <nevcairiel> still with the long term refs, huh
[17:03:33 CEST] <philipl> Well, not all of them. There are two samples that still fail but others with LTRs work
[17:03:45 CEST] <philipl> And I certainly can't see the problem in any real world clip.
[17:03:47 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/vaapi_hevc/libavcodec/vaapi_hevc.c#L245
[17:03:48 CEST] <BtbN> those 3
[17:04:01 CEST] <BtbN> LTRs should be fully implemented
[17:04:08 CEST] <philipl> but my nvidia contact is unresponsive these days so no progress there (this bug is in their reference player too so I can't compare to anything)
[17:04:43 CEST] <wm4> oh, if it's from gb, maybe wait what he has to say
[17:04:48 CEST] <nevcairiel> BtbN: st_rps_bits is easy
[17:04:50 CEST] <BtbN> yes, LTRPSPS_A_Qualcomm_1.bit plays fine.
[17:04:51 CEST] <philipl> At a guess, 'st_rps_bits' would be the number of its
[17:04:55 CEST] <wm4> haven't heard anything from him for almost a week though
[17:04:55 CEST] <philipl> bits
[17:05:14 CEST] <BtbN> at least i can't spot anything that looks wrong
[17:05:17 CEST] <nevcairiel> BtbN: look at dxva2_hevc.c, 94-97
[17:05:56 CEST] <nevcairiel> vaapi doesnt seem to have the other variable there, but the bit count variable is this one
[17:06:09 CEST] <philipl> right
[17:07:11 CEST] <nevcairiel> for the other two .. dxva has them too
[17:07:16 CEST] <nevcairiel> but i dont set them
[17:07:25 CEST] <philipl> dun dun dun.
[17:07:44 CEST] <nevcairiel> from the dxva spec:
[17:07:45 CEST] <nevcairiel> Note This flag does not correspond to any indication provided in the HEVC bitstream itself. Thus, a host software decoder would need some external information (e.g. as determined at the application level) to be able to set this flag to 1. In the absence of any such available indication, the host software decoder must set this flag to 0.
[17:08:15 CEST] <philipl> Odd. I guess it's in vaapi because it's in dxva?
[17:08:28 CEST] <nevcairiel> maybe it does serve some kind of purpose which i just dont understand
[17:08:51 CEST] <nevcairiel> the dxva spec was written by someone who knows hevc really well, so it must be of some use to someone
[17:10:42 CEST] <nevcairiel> setting them can probably yield some small performance optimizations
[17:12:48 CEST] <BtbN> I'll just leave them alone for now.
[17:26:20 CEST] <BtbN> https://bpaste.net/show/0aeee9f3a759 https://bpaste.net/show/f7f14df11de3
[17:26:34 CEST] <BtbN> At least the trace log thinks the ScalingList buffer is a VAIQMatrixBufferH264
[17:26:57 CEST] <nevcairiel> that may as well be a reason for a problem
[17:27:20 CEST] <BtbN> it does so for both gst and ffmpeg
[17:27:47 CEST] <BtbN> va_TraceVAIQMatrixBufferHEVC does exist though
[17:28:09 CEST] <nevcairiel> https://www.mail-archive.com/libva@lists.freedesktop.org/msg03203.html
[17:28:30 CEST] <nevcairiel> if thats the full extent of the problem, probably not related
[17:29:38 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/libva/tree/va/va_trace.c#n3240
[17:29:40 CEST] <BtbN> that's the problem
[17:29:45 CEST] <BtbN> copy-paste problem
[17:31:28 CEST] <BtbN> Not something that should affect decoding
[17:41:32 CEST] <BtbN> The ScalingLists ffmpeg produces are diffrent from what gst generates.
[17:41:39 CEST] <BtbN> Similar in most parts, but some are diffrent
[17:41:54 CEST] <nevcairiel> different how
[17:42:24 CEST] <BtbN> https://bpaste.net/show/87c85cfce8ec (gst)
[17:42:29 CEST] <BtbN> https://bpaste.net/show/8d7bbd4131cb (ffmpeg)
[17:42:44 CEST] <BtbN> starting at line ~320
[17:42:55 CEST] <nevcairiel> those are long scaling lists
[17:43:41 CEST] <kierank> some encoder optimised for metrics do that
[17:43:44 CEST] <kierank> encoders
[17:44:23 CEST] <nevcairiel> seems like the order is different
[17:45:08 CEST] <nevcairiel> but as gst also has issues decoding the files..
[19:10:09 CEST] <durandal_1707> anybody against pushing stack filters?
[19:10:34 CEST] <wm4> not me
[19:11:04 CEST] <Daemon404> me neither
[19:47:22 CEST] <kierank> is there a way to decode only iframes from ffmpeg.c or the api?
[19:53:24 CEST] <ubitux> kierank: skip_frame nokey?
[19:54:17 CEST] <kierank> ah thanks
[19:54:47 CEST] <kierank> just wanted to see what would happen with intrarefresh
[19:54:47 CEST] <ubitux> so, av_dict_set(&dec_opts, "skip_frame", "nokey", 0) probably
[19:55:01 CEST] <ubitux> but you can do it on the fly too
[19:55:29 CEST] <ubitux> avctx->skip_frame = AVDISCARD_NONKEY maybe
[20:05:50 CEST] <nevcairiel> kierank: probably doesnt output anything with intra refresh =p
[20:06:28 CEST] <kierank> Yeah
[20:06:31 CEST] <kierank> Totally empty
[00:00:00 CEST] --- Thu Aug 27 2015
1
0
[07:57:05 CEST] <fling> How to encode different parts of video with different quality?
[08:05:56 CEST] <pzich> fling: split it into pieces, encode, then stitch them together?
[08:06:17 CEST] <fling> pzich: good idea!
[08:06:36 CEST] <fling> pzich: how to split based on the amount of movement on the video?
[08:07:55 CEST] <pzich> no idea, but I think ffmpeg has a few stabilization filters, they might be able to tell you how much motion is at different parts of the video
[08:10:02 CEST] <fling> I have a bunch of videos from a security camera and I wanted to only keep parts containing movement&
[08:10:25 CEST] <fling> pzich: another question is how to deal with a really desynced video? The video looks running much faster than audio there.
[10:25:58 CEST] <k_sze> Does ffmpeg/libav rearrange memory of "expired" frames under the hood?
[10:28:51 CEST] <k_sze> I mean, if I'm demuxing and decoding frames(), without setting AVCodecContext.refcounted_frames, does ffmpeg have a background thread that rearranges the memory of any frame except the current one, such that the content of the buffer of those old frames can change spontaneously from my application's perspective?
[10:46:35 CEST] <TikityTik> Is there a way to have ffmpeg stream and interactively play,pause, and choose what files play?
[11:58:59 CEST] <amol> hello
[12:03:55 CEST] <durandal_1707> hello
[12:25:53 CEST] <amol> Binary file of ffplay is not created after compiling ffmpeg source code. I download source from official site & did, 1)./configure 2)make 3) make install. Also SDL library is also installed. help me out this..
[12:26:48 CEST] <c_14> Is SDL 1 installed or SDL2 ?
[12:28:30 CEST] <amol> SDL-1_2-0
[12:30:29 CEST] <c_14> Can you pastebin your config.log ?
[12:32:30 CEST] <amol> ok but it's more than 10,000 lines
[12:33:51 CEST] <c_14> It tends to do that, yeah.
[13:42:17 CEST] <turlando> Hello everyone
[13:45:35 CEST] <turlando> I'm trying to transode a flac file to ogg vorbis using libvorbis but ffmpeg segfaults leaving me with a 0 byte file. here you can find a full log http://sprunge.us/jJjB
[13:46:08 CEST] <turlando> In that paste you'll find the version and the configure options too
[13:46:44 CEST] <c_14> I'm assuming you meant -ar and not -ab
[13:46:59 CEST] <c_14> Does it still segfault if you change that?
[13:47:57 CEST] <turlando> c_14, yes, it still does that
[13:48:17 CEST] <turlando> I tried to do a flac->flac conversion but the generated flac still segfaults ffmpeg converting to vorbis
[13:48:48 CEST] <c_14> Can you either upload the input file, the core dump, or a backtrace from the coredump?
[13:49:17 CEST] <turlando> c_14, is strace <command> fine for the purpose?
[13:50:14 CEST] <c_14> Could be useful, but that doesn't tell me where in the code it segfaults.
[13:50:22 CEST] <tinpl> Hi guys& I'm trying to build project using ffmpeg, but stucked on linker errors: http://pastebin.com/h6QBwrwk
[13:50:39 CEST] <tinpl> could anyone tell me where I could make a mistake?
[13:50:40 CEST] <turlando> How do I get a core dump? Do I need to recompile ffmpeg with some debug symbols?
[13:51:03 CEST] <c_14> ulimit -c unlimited; then rerun the command
[13:51:53 CEST] <c_14> The core dump itself shouldn't require the symbols, they should only be necessary when running gdb to check the contents of the dump (iirc)
[13:53:02 CEST] <turlando> Here you go c_14 http://sprunge.us/BjGO
[13:53:47 CEST] <c_14> turlando: there should be a file called `core' in your cwd now
[13:54:31 CEST] <turlando> Strange, there isn't... let me try again
[13:55:17 CEST] <c_14> Did you run ulimit -c unlimited before?
[13:55:23 CEST] <turlando> Yes, I did
[13:55:50 CEST] <turlando> It doens't show up: ls: cannot access core: No such file or directory
[13:56:07 CEST] <c_14> you can use `ulimit -c' to check that it set it correctly
[13:56:41 CEST] <turlando> It returns unlimited
[13:56:44 CEST] <c_14> hmm
[13:57:34 CEST] <c_14> Can you check /proc/sys/kernel/core_pattern ?
[13:58:18 CEST] <turlando> It returns |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e
[13:58:27 CEST] <c_14> geh
[13:58:29 CEST] <c_14> eeeeh
[13:58:37 CEST] <turlando> lol
[13:58:48 CEST] <c_14> You can either change it to "core" or try and find out what systemd does with coredumps
[13:58:52 CEST] <c_14> (probably in the journal somewhere)
[13:59:18 CEST] <turlando> Does it redirects the core file to the journalctl maybe?
[13:59:32 CEST] <c_14> >/var/lib/systemd/coredump, or directly in the journal.
[13:59:35 CEST] <c_14> according to the manpage
[13:59:55 CEST] <c_14> Ah, you can use coredumpctl to extract them
[14:00:15 CEST] <c_14> coredumpctl dump /path/to/ffmpeg
[14:00:24 CEST] <turlando> last two lines of journalctl http://sprunge.us/fgbd
[14:01:22 CEST] <turlando> maybe I found that, I'm uploading it
[14:03:35 CEST] <c_14> tinpl: no clue. configure was successful?
[14:04:13 CEST] <turlando> c_14 at coselosche.org/~tancredi/ffmpeg you'll find the trace. The flac file is still uploading
[14:06:05 CEST] <tinpl> A_14 seems so, and produced all libs fine. at least there were only some warnings
[14:07:03 CEST] <c_14> Is this when compiling ffmpeg or when linking against it?
[14:07:48 CEST] <tinpl> when linking
[14:07:53 CEST] <tinpl> compile went fine
[14:08:04 CEST] <tinpl> as I told it produced all .a objects
[14:08:19 CEST] <tinpl> with no errors
[14:10:26 CEST] <turlando> c_14 the flac finished uploading by the way
[14:10:43 CEST] <c_14> turlando: did you compress the coredump somehow? file can't figure out what it is and lz4 is telling me the header's wrong
[14:11:34 CEST] <turlando> c_14, it is how I found it in my coredump directory...
[14:14:08 CEST] <turlando> c_14, sorry, I never used coredumpctl, here should be what you want http://sprunge.us/aVKi
[14:14:42 CEST] <c_14> yeah, I can reproduce it here
[14:15:56 CEST] <c_14> That's definitely a bug.
[14:16:22 CEST] <turlando> How do we say if it is on libvorbis or ffmpeg handing it?
[14:16:55 CEST] <c_14> It's ffmpeg.
[14:17:07 CEST] <c_14> It's when writing the tags for the ogg container, not when encoding the stream.
[14:17:13 CEST] <c_14> You can reproduce the crash with libopus
[14:18:08 CEST] <c_14> Probably time for a bugreport: https://ffmpeg.org/bugreports.html
[14:18:22 CEST] Action: c_14 is just going to test with a newer git version to see if it's still in master
[14:18:36 CEST] <turlando> I thought it was because of the album art embedded as a video stream, so I gave it -map 0:a as you have seen
[14:18:58 CEST] <turlando> Thank you very much for trying the git version for me
[14:19:27 CEST] <turlando> Meanwhile I'll try to strip out the tags from the flac files and try the transcode again
[14:27:49 CEST] <c_14> turlando: crash also occurs in git. You can attach the information from here: http://pb.c-14.de/t/kng.DhAqnj to the bugreport if you don't feel like reproducing it yourself. (either directly in the description of the bugreport or as an attachment)
[14:29:27 CEST] <turlando> Thank you very much c_14. Stripping the vorbis comments resulted in a successfull transcode
[14:29:39 CEST] <turlando> I'll file the bug report right now
[14:32:00 CEST] <turlando> c_14 do I need to attach a media sample too?
[14:33:05 CEST] <durandal_1707> yes
[14:33:15 CEST] <c_14> It's usually helpful. Allows devs to reproduce the issue and make sure the patch fixes it. The flac is probably too large to attach so you can upload it to the ftp.
[14:36:16 CEST] <turlando> Will dd preserve the file structure in order to reproduce the bug?
[14:37:12 CEST] <c_14> Are you talking about trimming the file?
[14:39:07 CEST] <turlando> Yes, I do
[14:39:12 CEST] <turlando> I am*
[14:39:29 CEST] <c_14> Try it out, then rerun the ffmpeg command and see if it still segfaults
[14:40:20 CEST] <turlando> Of couse I will
[14:41:20 CEST] <turlando> Is "I'm trying to transcode this flac file to libvorbis but ffmpeg will just segfault while creating the metadata structure." okay as text file to upload to the ftp alongside the flac?
[14:42:10 CEST] <c_14> should be ok as long as you also attach the ffmpeg output stuff I uploaded earlier
[14:42:50 CEST] <c_14> And truncating the flac appears to work (it still segfaults after I truncated the input to 2M)
[14:43:51 CEST] <turlando> c_14, I supposed I should attach it to the bug tracker
[14:44:00 CEST] <c_14> yes
[14:45:24 CEST] <turlando> So it doens't need to go to the ftp
[14:45:46 CEST] <turlando> Sorry for the bunch of questions but it is my very first ffmpeg bug report
[14:45:59 CEST] <turlando> And I would like to help the devs as much as I can
[14:46:43 CEST] <c_14> If it's small enough that you can upload it to trac, put it there.
[14:47:48 CEST] <turlando> Is 2MB fine for the trac?
[14:48:22 CEST] <c_14> I think the limit is 5MiB, but I'm not sure
[14:52:48 CEST] <tinpl> guys, I'm using this configure, is it OK? PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" --pkg-config-flags="--static" --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib" --bindir="$HOME/bin" --enable-gpl --enable-libass --enable-libtheora --enable-libvorbis --enable-libx264 --enable-avresample
[15:01:56 CEST] <turlando> c_14, it is afflicting avcodec, right?
[15:08:18 CEST] <c_14> avformat
[15:09:45 CEST] <turlando> Thank you
[15:10:06 CEST] <turlando> May I CC you to the bug report c_14?
[15:12:56 CEST] <c_14> I'll add myself later.
[15:13:20 CEST] <Hero6666> Hi there
[15:15:59 CEST] <Hero6666> I need your help. First compiling FFmpeg on Win64. Thereis my config.log : rob9.net/tmp/config.log
[15:18:09 CEST] <turlando> c_14 you'll find the bug report here https://trac.ffmpeg.org/ticket/4806
[15:25:49 CEST] <idi0tically> Hi everyone.
[15:28:15 CEST] <Hero6666> Anyone an idea, why my compiler cannot find libaries I try to compile with ffmpeg?
[15:29:02 CEST] <maksimka> hello
[15:29:47 CEST] <maksimka> how can i set duration for every image i want to use in video (I have 30 images and I will to view every image of them for variable number of milliseconds)
[15:30:19 CEST] <idi0tically> I've got a weird matroska muxing problem... a few days ago a I transcoded a file (matroska container, 03:48:11 duration, h264 video, 1 dts-hd ma master audio stream and 4 directors commentaries in stereo ac3 + pgs subtitles) down to hevc/opus in a matroska container
[15:31:26 CEST] <idi0tically> That worked fine, but after doing a similar transcode for another file, I decided I wanted a higher bitrate for 6.1 master audio track (up from 448 to 896kbps), so i transcoded the audio from the source again seperately
[15:31:39 CEST] <Hero6666> @maksimka: -delay should work
[15:32:51 CEST] <idi0tically> Now I'm using the command line "ffmpeg -i FOTR-lowspec.mkv -i newaudio.opus -map 0:v -map 1:a:0 -map 0:a:1 -map 0:a:2 -map 0:a:3 -map 0:a:4 -map 0:s -c:v copy -c:a copy -c:s copy FOTR-lowspec2.mkv" to try and mux the streams together; but when I do I get no master audio stream in the output (directors commentaries work fine tho)
[15:34:53 CEST] <idi0tically> I also get a bunch of warnings from the matroska muxer like "Starting new cluster due to timestamp"
[15:35:57 CEST] <maksimka> Hero6666: could you point to an example please? couldn't find any for -delay..
[15:43:20 CEST] <Hero6666> @maksimka: http://ffmpeg.org/ffmpeg-all.html#toc-Examples-115
[15:56:54 CEST] <idi0tically> This really odd though.. if I extract the audio out from my file (with mkvextract) it's perfectly fine, but it doesn't playback in mplayer, kodi or ffplay (the last of which defaults to ignore the master audio stream and playback the 1st directors commentary)
[16:28:43 CEST] <thecoolguy> Hello
[16:29:16 CEST] <thecoolguy> Anyone here ?
[16:37:51 CEST] <klaxa|work> thecoolguy: no (yes)
[16:38:48 CEST] <thecoolguy> trying to transcode form a url but i get http://pastie.org/private/mtwuwnnvurmx1ptxp2uw
[16:39:49 CEST] <klaxa|work> it says you are trying to encode 0 audio channels
[16:40:48 CEST] <klaxa|work> what command did you run?
[16:41:31 CEST] <thecoolguy> ffmpeg -i myurl -b:a 32k output.mp4
[16:42:33 CEST] <klaxa|work> that's pretty weird, that should work
[16:43:30 CEST] <klaxa|work> what ffmpeg version do you have?
[16:43:54 CEST] <thecoolguy> how do i check ?
[16:44:22 CEST] <klaxa|work> when you run ffmpeg it tells you at the beginning
[16:44:32 CEST] <thecoolguy> http://pastie.org/private/fhocvwt9z7zamdgkajmh4w
[16:45:56 CEST] <thecoolguy> [libvo_aacenc @ 0000000004ddc920] Unable to set encoding parameters
[16:46:02 CEST] <thecoolguy> why would that occur ?
[16:46:12 CEST] <klaxa|work> hmm dunno not using aacenc
[16:46:24 CEST] <klaxa|work> libfdk-aac is better
[16:46:48 CEST] <klaxa|work> i can imagine that some downmixing stuff is responsible
[16:47:09 CEST] <klaxa|work> your input has 6 channels, not sure how that is dealt with
[16:47:17 CEST] <thecoolguy> how do i specify that as a parameter ?
[16:47:40 CEST] <klaxa|work> -ac 6 maybe?
[16:47:49 CEST] <klaxa|work> that tells ffmpeg to use 6 audio channels
[16:47:58 CEST] <klaxa|work> but i'm not sure if that will work
[16:48:29 CEST] <thecoolguy> no i mean to use the other encode you mentioned
[16:48:50 CEST] <klaxa|work> ah, try adding -c:a libfdk_aac
[16:53:09 CEST] <thecoolguy> ugh missing
[16:53:53 CEST] <thecoolguy> are there any others i can use that come with ffmpeg
[16:53:59 CEST] <c_14> -c:a aac
[16:55:06 CEST] <klaxa|work> doesn't that use libvo_aacenc?
[16:55:20 CEST] <c_14> No, that's the name of the internal aac encoder
[16:55:20 CEST] <klaxa|work> well it really shouldn't mess with channel layout should it?
[16:55:24 CEST] <klaxa|work> ah right
[16:56:21 CEST] <thecoolguy> The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it.
[16:56:53 CEST] <thecoolguy> o got it now
[16:57:44 CEST] <thecoolguy> Yup it seems to be orking
[16:58:37 CEST] <thecoolguy> is there a codecs that uses nvenc?
[16:59:11 CEST] <klaxa|work> for audio? i don't think so, i think the only ones supported are h264 and h265 and i'm not even sure about h265
[16:59:31 CEST] <klaxa|work> according to wikipedia h264
[16:59:33 CEST] <c_14> There is nvenc_hevc
[16:59:36 CEST] <c_14> and nvenc_h264
[16:59:40 CEST] <klaxa|work> oh?
[16:59:42 CEST] <klaxa|work> https://en.wikipedia.org/wiki/Nvidia_NVENC
[16:59:44 CEST] <thecoolguy> :o
[17:00:10 CEST] <klaxa|work> >Introduced with the second-generation Maxwell architecture, third generation NVENC implements the video compression algorithm High Efficiency Video Coding (aka. HEVC, H.265) [...]
[17:00:20 CEST] Action: c_14 even tried it out once
[17:00:27 CEST] <klaxa|work> is it any good?
[17:00:33 CEST] <thecoolguy> Was it reasonable faster ? i have a gtx970
[17:00:42 CEST] <thecoolguy> reasonably*
[17:00:49 CEST] <c_14> For h264 or h265?
[17:00:54 CEST] <klaxa|work> both
[17:01:12 CEST] <c_14> It's much faster for h265, but neither is better than x264 --preset ultrafast
[17:01:17 CEST] <c_14> When it comes to speed/quality
[17:01:29 CEST] <c_14> (at least not yet)
[17:02:58 CEST] <thecoolguy> Really, thought it converting is signigicantly faster using gpu accelration
[17:55:45 CEST] <thecoolguy> klaxa stil lthere ?
[17:56:21 CEST] <thecoolguy> how would i do ffmpeg->vlc->http?
[18:02:51 CEST] <klaxa> thecoolguy: dunno maybe named pipes and multiple processes?
[18:03:05 CEST] <klaxa> or use (cough) ffserver
[18:05:12 CEST] <thecoolguy> ok just donwloaded it what would be the command line for say an mp4 stream given my starting command is. ffmpeg -i myurl -ac 6 -strict -2 -c:a aac -f mp4 output.mp4
[18:06:38 CEST] <thecoolguy> aya it doesn't exist on windows :/
[18:06:41 CEST] <thecoolguy> yay*
[18:07:15 CEST] <klaxa> ah i thought you were on linux
[18:07:36 CEST] <klaxa> shouldn't you be able to just give the url to vlc?
[18:07:49 CEST] <klaxa> vlc also has some transcoding options
[18:08:30 CEST] <thecoolguy> i tried something like
[18:08:31 CEST] <thecoolguy> vlc myurl :sout=#transcode{vcodec=hevc,acodec=mpga,ab=128,channels=2,samplerate=44100} :sout-keep
[18:08:42 CEST] <thecoolguy> with vlc but it doesn't even connect to my url :/
[18:10:17 CEST] <klaxa> sorry i have no experience with vlc regarding that
[18:11:02 CEST] <thecoolguy> god windows 10 is an abombination x.x
[18:12:06 CEST] <thecoolguy> what about with icecast?
[18:21:48 CEST] <thecoolguy> klaxa how would i fix the error muxer does not support non seekable output
[18:22:06 CEST] <klaxa> use a different container
[18:22:48 CEST] <thecoolguy> or is my command wrong?
[18:23:28 CEST] <thecoolguy> doing
[18:23:33 CEST] <thecoolguy> ffmpeg -i url -ac 6 -strict -2 -c:a aac icecast://user:pass@localhost:8000/earth:video.mp4
[18:32:18 CEST] <JEEB> so if I need to generate silent audio, I guess it'd be aevalsrc, or is there a shorthand for it?
[18:33:39 CEST] Action: c_14 always uses aevalsrc=0, not sure if there's something better. you could also read pcm from /dev/zero
[18:39:52 CEST] <durandal_1707> anullsrc?
[18:46:58 CEST] <thecoolguy> ok klaxa
[18:47:26 CEST] <thecoolguy> I'm doing ffmpeg -i url -ac 6 -strict -2 -c:a aac -g 10 -f mp4 "icecast://source:hackme@localhost:8000/stream"
[18:47:33 CEST] <thecoolguy> and getting muxer does not support non seekable output
[18:47:39 CEST] <c_14> thecoolguy: you can't stream mp4
[18:47:59 CEST] <thecoolguy> what can i stream that would be ios compatible ?
[18:51:11 CEST] <thecoolguy> c_14 ?
[18:52:30 CEST] <c_14> hls
[18:52:46 CEST] <c_14> That won't work via icecast though.
[19:00:48 CEST] <thecoolguy> hm
[19:04:57 CEST] <thecoolguy> do you know anything that does
[20:29:54 CEST] <iulhk> how can i use ffmpeg to convert m4a file to wav 8000 khz?
[20:30:26 CEST] <thecoolguy> anyone ever use nginx ?
[20:30:58 CEST] <c_14> iulhk: ffmpeg -i m4a -ar 8000k out.wav
[20:31:08 CEST] <c_14> Though, you probably didn't mean 8000 kiloherz...
[20:45:03 CEST] <iulhk> <c_14>: i need 8khz , the upper command is not working for me
[20:45:56 CEST] <c_14> just use 8000
[20:46:31 CEST] <iulhk> <c_14>: not even without khz ,
[20:52:12 CEST] <chungy> unrelated, but why do you want 8kHz? o.O
[20:53:39 CEST] <retard> thecoolguy someone sometime used nginx
[20:54:36 CEST] <iulhk> <fflogger>: http://pastie.org/10377653
[20:55:07 CEST] <iulhk> <chungy>: where i required its only support 8000 khz mono audio
[20:55:34 CEST] <c_14> iulhk: if you want mono add -ac 1
[20:57:17 CEST] <iulhk> <c_14>: getting error this way "ffmpeg -i myfile.m4a -ac -ar 8000 1440606849.wav"?
[20:57:24 CEST] <c_14> -ac 1
[20:59:51 CEST] <iulhk> <c_14>: Thanks buddy :) its working now
[21:01:26 CEST] <chungy> "8k" also works as an alternative to 8000
[22:17:35 CEST] <tommd> I'm seeing odd error numbers, could someone give me a hint? For example, -1330794744 on avformat_open_input
[22:22:29 CEST] <tommd> Ahh, protocol not found.
[22:22:45 CEST] <tommd> so.. I don't know what that means yet though if anyone wants to chime in.
[22:23:23 CEST] <klaxa> post some code then
[22:24:16 CEST] <tommd> Is there no small set of things "protocol not found" refers to?
[22:24:37 CEST] <tommd> I could extract some C from my Haskell bindings if needed, but it might be quicker if I slog along a little longer in that case.
[22:26:37 CEST] <klaxa> why not just paste the haskell code?
[22:26:47 CEST] <klaxa> or is it too far from the C api?
[22:29:16 CEST] <tommd> OK, it's from ffurl_alloc, which is the only function that returns protocol not found and is reachable from avformat_open_input.
[22:29:34 CEST] <klaxa> what are you passing ffurl_alloc?
[22:29:43 CEST] <tommd> klaxa: I could have! It's just: imageReader "0:0"
[22:29:55 CEST] <klaxa> haha ok
[22:30:08 CEST] <tommd> So I use ffmpeg-light and call `imageReader "0:0"` hoping the a/v format is parsed correctly.
[22:30:26 CEST] <tommd> So... I learned that, while it might be parsed correctly, my notion of 'correct' is wrong.
[22:30:36 CEST] <klaxa> what is "0:0" ? is it a file?
[22:30:54 CEST] <tommd> klaxa: No, it is my lame attempt to open my camera via avfoundation
[22:31:29 CEST] <tommd> I think "video=???" might work, so hints a few pages, but I can't get anything going and don't have time for looking over avio.c right now.
[22:31:46 CEST] <tommd> Do you have a hint?
[22:34:49 CEST] <klaxa> hmm...
[22:46:08 CEST] <JEEB> durandal_1707: so anullsrc works just like that? nice
[22:48:34 CEST] <durandal_1707> maybe you can get random noise but do not...
[22:54:41 CEST] <JEEB> what?
[22:57:19 CEST] <JEEB> yeah, decoding the stream makes it long and enough and it seems zero'd?
[22:57:23 CEST] <JEEB> cheers, m8
[00:00:00 CEST] --- Thu Aug 27 2015
1
0