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

[burek]

[03:12:18 CET] <kierank> why is there no function to free a VLC table?
[03:13:45 CET] <kierank> oh there is I am blind
[03:18:26 CET] <cone-197> ffmpeg 03Mats Peterson 07master:57631f1851ef: avformat: factor ff_get_qtpalette() out of mov.c
[03:18:26 CET] <cone-197> ffmpeg 03Mats Peterson 07master:797360384373: avformat/matroskadec: palettized QuickTime video in Matroska
[03:31:01 CET] <J_Darnley> Wow.  Somehow gcc has done these intrinsics much better on Windows than on Linux.  (It is more likely to be 4.9 vs 5.3)
[03:45:30 CET] <llogan> wasn't expecting any of that "palettized" stuff would actually get pushed
[04:00:24 CET] <RiCON> what an adventure
[04:08:27 CET] <Daemon404> indeed
[04:19:45 CET] <Compn> ancient quicktime is arcane
[04:56:19 CET] <tmm1> can someone help me understand the pts handling in the w3fdif and yadif filters?
[04:57:34 CET] <tmm1> the second frame emitted has out->pts = cur_pts + next_pts
[05:02:05 CET] <tmm1> having a hard time grokking why that makes sense
[05:53:33 CET] <tmm1> oh, it works because all the other frames have their pts doubled
[10:18:20 CET] <cone-204> ffmpeg 03Michael Niedermayer 07master:ca9e3cb3ce7a: avformat/qtpalette: Move ff_get_qtpalette() doxy to header
[10:18:20 CET] <cone-204> ffmpeg 03Michael Niedermayer 07master:3c6781b48acd: Revert "ffplay: Fix auto insertion point of rotation filter"
[10:24:50 CET] <cone-204> ffmpeg 03Hendrik Leppkes 07master:50401f5fb7d7: avcodec: properly check pkt_timebase for validity
[12:45:46 CET] <cone-204> ffmpeg 03Paul B Mahol 07master:b841fe002a2b: avfilter/af_silenceremove: lower number of operations in for loop
[12:45:47 CET] <cone-204> ffmpeg 03Paul B Mahol 07master:47aaebd63e40: avfilter/af_silenceremove: make size of window user configurable
[12:45:48 CET] <cone-204> ffmpeg 03Paul B Mahol 07master:397774603690: doc/filters: add one more silenceremove example
[14:37:24 CET] <durandal_170> tmm1: still need help?
[16:11:46 CET] <cone-204> ffmpeg 03Rodger Combs 07master:4caa3e1c6cf4: lavf: add API to apply a list of bsfs to a packet
[16:11:47 CET] <cone-204> ffmpeg 03Rodger Combs 07master:a5fd3a1a2bd2: ffmpeg: use lavf API for applying bitstream filters
[16:11:48 CET] <cone-204> ffmpeg 03Rodger Combs 07master:7a161b74ad13: lavf/tee: use lavf API for applying bitstream filters
[16:11:49 CET] <cone-204> ffmpeg 03Rodger Combs 07master:1f9139b07b8a: lavf: add automatic bitstream filtering; bump version
[16:11:50 CET] <cone-204> ffmpeg 03Rodger Combs 07master:822e80fde39f: lavf: add internal API to append a bsf to a stream's list
[16:11:51 CET] <cone-204> ffmpeg 03Rodger Combs 07master:b287d7ea17f4: lavf/matroskaenc: add automatic bitstream filtering
[16:11:52 CET] <cone-204> ffmpeg 03Rodger Combs 07master:1b5bd4051d1e: lavf/mpegtsenc: add automatic bitstream filtering
[16:13:43 CET] <ubitux> @_@
[16:30:23 CET] <nevcairiel> cant we just ban that guy already
[16:31:09 CET] <durandal_170> who?
[16:32:34 CET] <JEEB> the matias guy?
[16:32:40 CET] <ubitux> :D
[16:35:25 CET] <rcombs> no, me
[16:36:33 CET] <nevcairiel> yeah, how dare you make the life of ffmpeg cli users easier
[16:36:42 CET] <nevcairiel> they deserve to suffer!
[16:39:42 CET] <saste> ah cool, that got in, kudos rcombs :-)
[16:39:46 CET] <rcombs> \o/
[16:40:28 CET] <atomnuker> holy shit that's a huge thread
[16:41:00 CET] <ubitux> it's mostly the work of a single man derping at himself
[16:41:25 CET] <ubitux> the guy sounds really crazy
[16:41:48 CET] <durandal_170> atomnuker: still gonna do showspectrumpic?
[16:42:20 CET] <atomnuker> that's a good idea actually, was just wondering what to do
[16:48:45 CET] <BBB> rcombs: \o/
[16:49:00 CET] <BBB> rcombs: now we need to automatically pack vp9 superframes in the encoders (ivf, mkv)
[16:49:18 CET] <rcombs> BBB: I've no idea how those work
[16:49:45 CET] <nevcairiel> BBB just needs to write  a bsf to do it
[16:49:46 CET] <BBB> its the inverse of vp9_parser.c
[16:49:51 CET] <BBB> bt Im lazy
[16:49:59 CET] <BBB> I want someone else to do it
[16:50:20 CET] <rcombs> in the encoder or in the muxer?
[16:50:28 CET] <BBB> you have to think of future generations, theyll notice that any different guys contributed to vp9, so vp9 must have been really important
[16:50:40 CET] <BBB> I dont think rcombs has vp9 patches yet, so Im trying to get him to write one :-p
[16:50:42 CET] <BBB> rcombs: muxer
[16:50:47 CET] <nevcairiel> rcombs: in between :D
[16:50:57 CET] <BBB> its for the transmuxing case, where no encoder exists
[16:51:09 CET] <BBB> vp9_parser will split but nothing will join them back together
[16:51:12 CET] <BBB> which is kind of annoying
[16:51:26 CET] <BBB> like -c:v copy
[16:51:28 CET] <rcombs> if it's just "if it's VP9, put it through this BSF", ^^that can handle it
[16:51:41 CET] <rcombs> there just has to actually be a BSF for it
[16:51:45 CET] <nevcairiel> its just that this particular BSF does not exist yet :)
[16:51:55 CET] <BBB> oh I see you guys want me to write the bsf
[16:51:58 CET] <BBB> grmbl
[16:52:11 CET] <rcombs> I know jack shit about VPX
[16:52:18 CET] <nevcairiel> you actually know what needs to happen in there!
[16:52:36 CET] <BBB> legit argument
[16:52:38 CET] <BBB> but!
[16:52:45 CET] <BBB> I could teach you what needs to happen in there
[16:53:06 CET] <durandal_170> everything should be usable through lavfi
[16:53:22 CET] <nevcairiel> i already know way more about vp9 than I want to
[16:53:46 CET] <BBB> :(
[16:54:33 CET] <nevcairiel> but it can be hardware decoded now, so thats a bonus
[16:54:56 CET] <cone-204> ffmpeg 03Joel Holdsworth 07master:b9c46b5242bf: avformat/http: Documented http_proxy option
[16:55:02 CET] <rcombs> my users still don't care about VPX
[16:55:16 CET] <wm4> but they should
[16:55:45 CET] <BBB> doesnt youtube use it or so?
[16:56:07 CET] <rcombs> sure
[16:56:30 CET] <rcombs> but I don't think I ever have to remux it
[16:56:32 CET] <nevcairiel> vp9 probably is quite a substantial part of streamed internet video, just by being on youtube
[16:56:46 CET] <ubitux> mmh, isn't youtube-dl remuxing the vp9 parts?
[16:56:49 CET] <wm4> isn't the problem that there's still no good vp9 encoder?
[16:57:04 CET] <nevcairiel> its not that terrible anymore
[16:58:30 CET] <atomnuker> 1.4 is über slow and its debian maintainer has gone AWOL so we're stuck with it
[16:58:44 CET] <nevcairiel> you choose to use debian
[16:58:45 CET] <nevcairiel> so...
[16:58:48 CET] <wm4> which debian maintainer?
[16:59:24 CET] <atomnuker> wm4: Sebastian Dröge, https://packages.qa.debian.org/libv/libvpx.html
[16:59:58 CET] <wm4> don't know how to read this, but doesn't look very AWOL
[17:00:23 CET] <nevcairiel> apparently 1.5 was accepted into unstable just today
[17:02:09 CET] <atomnuker> awesome, maybe now I can encode 5 seconds @24fps in less than 3 hours
[17:40:58 CET] <kierank> michaelni: can you explain this line: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/snow.c#L562
[17:41:08 CET] <kierank> why do you add stride >> 1 to buf
[17:44:56 CET] Action: Daemon404 wonders why kierank is reading snow
[17:45:08 CET] <kierank> gotta make cfhd do the same thing
[17:45:28 CET] <kierank> not 100% sure how to store the coefficients
[17:47:28 CET] <Daemon404> o
[17:57:12 CET] <michaelni> kierank, dont remember exactly but it must have been to have buf at the rigt spot
[18:03:53 CET] <atomnuker> anyone likes reading 6000+ line patches on the ML?
[18:04:20 CET] <ubitux> TLDR LGTM
[18:05:12 CET] <wm4> "probably ok"
[18:08:36 CET] <smarter> Daala decoder incoming?
[18:10:39 CET] <kierank> what's a bit odd about cfhd is that there are extra coefficients
[18:13:02 CET] <Daemon404> atomnuker, the bitstream format is frozen now isnt it?
[18:13:04 CET] <Daemon404> or did they give that up
[18:14:23 CET] <smarter> Daala? We're pretty far from freezing the bitstream
[18:14:27 CET] <atomnuker> not frozen by a longshot
[18:15:02 CET] <smarter> Yeah there was a plan for freezing at end of 2015 but that was before the IETF standardization effort, AOM, etc
[18:16:38 CET] <Daemon404> smarter, so the '2015 freeze' that was sung for 2 years was given up on
[18:16:43 CET] Action: Daemon404 predicted correctly
[18:16:58 CET] <smarter> congrats I guess :)
[18:23:32 CET] <Daemon404> ubitux, do we still need arm stuff for FATE?
[18:23:39 CET] <Daemon404> i have a a9 that has sat idle for 2 years
[18:23:47 CET] <Daemon404> either itll be a fate cli or ill bin it
[18:23:52 CET] <ubitux> no idea
[18:23:59 CET] <ubitux> i think we actually need more tests
[18:24:02 CET] <ubitux> but well :p
[18:24:07 CET] <Daemon404> i could add a native clang/arm
[18:28:23 CET] <Daemon404> oh good im 2 versions of fedora out of date on this arm box
[18:28:29 CET] <Daemon404> see you in 2 weeks when it finishes updating
[18:30:56 CET] <cone-204> ffmpeg 03Paul B Mahol 07master:67771ac4b894: avfilter/avf_showspectrum: add rscroll sliding mode
[18:39:26 CET] <rcombs> so Comcast is switching from MPEG-2 to AVC, if anyone cares
[18:39:33 CET] <rcombs> for HD channels
[18:40:48 CET] <Daemon404> welcome to 10 years ago?
[18:40:56 CET] <Daemon404> i wonder how bad their encoder will be
[18:41:18 CET] <kierank> it's an ongoing process
[18:42:24 CET] Action: TD-Linux can't wait for his AVC reencodes of MPEG-2 streams
[18:43:05 CET] <Daemon404> that descriebs mostly any scene release
[19:04:51 CET] <cone-204> ffmpeg 03Paul B Mahol 07master:45b3e6e04e8e: avfilter: move window function generation into separate file
[19:04:52 CET] <cone-204> ffmpeg 03Paul B Mahol 07master:f88546b426af: avfilter/avf_showspectrum: use ff_generate_window_func
[19:09:28 CET] <llogan> rcombs: do the docs need to be updated to mention autobsf?
[19:10:03 CET] <rcombs> probably something somewhere
[19:10:40 CET] <llogan> doc/bitstream_filters.texi
[19:35:08 CET] <BBB> atomnuker: oo a daala decoder
[19:35:51 CET] <BBB> atomnuker: so why is it blockier? does that mean you didnt implement loopfilter yet?
[19:36:00 CET] <BBB> and pframe support sounds missing also?
[19:36:09 CET] <nevcairiel> he did mention all that =p
[19:36:15 CET] <nevcairiel> missing filter, only I frames
[19:37:08 CET] <Daemon404> can the daala encoder even make p frames
[19:38:00 CET] <BBB> who needs p frames anyway
[19:38:10 CET] <nevcairiel> go straight to B!
[19:38:39 CET] <rcombs> clearly we must invent new types of frames
[19:39:20 CET] <rcombs> anyone with ideas for how T-frames should work should send their suggestions to someone else
[19:39:44 CET] <atomnuker> BBB: there is a loop filter, but there is no deringing filter
[19:58:15 CET] <llogan> looks like gstreamer does regression tests too https://ci.gstreamer.net/
[20:39:33 CET] <cone-204> ffmpeg 03Paul B Mahol 07master:4020787b5bbd: avfilter/avf_showspectrum: make colors for log scale more user friendly
[21:07:56 CET] <smarter> Daemon404: the daala encoder has had p frames for a long time, and got b frames recently
[21:14:15 CET] <BtbN> What's even the state of Daala? I thought it was still unfinished and changing a lot
[21:14:42 CET] <smarter> yes
[21:16:59 CET] <smarter> atomnuker: you wrote "ratser" instead of "raster" in a bunch of places
[21:21:05 CET] <cone-204> ffmpeg 03James Almer 07master:6e243d17e911: x86/vf_stereo3d: optimize register usage
[21:21:06 CET] <cone-204> ffmpeg 03James Almer 07master:1817643d4f50: x86/vf_stereo3d: make ff_anaglyph_sse4 work on x86_32
[21:28:03 CET] <Daemon404> smarter, o ok
[21:55:43 CET] <atomnuker> smarter: fixed, thanks
[22:01:07 CET] <atomnuker> libvpx 1.5.0: "This release improves upon the VP9 encoder and speeds up the encoding and decoding processes."
[22:01:12 CET] <atomnuker> "frame=  195 fps=0.0 q=0.0 size=     208kB time=00:00:06.55 bitrate= 260.2kbits/s speed=0.000856x"
[22:01:33 CET] <atomnuker> this has been going on for 3 hours, this is just as slow as 1.4.0
[22:01:56 CET] <nevcairiel> sounds like your system is a RPi or you are using insane settings
[22:02:06 CET] <nevcairiel> i can get decent speeds out of 1.5 now
[22:02:25 CET] <atomnuker> -b:a 1M -quality best sounds reasonable
[22:02:36 CET] <atomnuker> s/b:a/b:v
[22:03:06 CET] <nevcairiel> they dont recommend using best,  fwiw
[22:03:11 CET] <nevcairiel> its like placebo
[22:03:19 CET] <nevcairiel> use good with some cpu-used parameter
[22:04:20 CET] <smarter> never use best
[22:04:22 CET] <nevcairiel> ie, good with --cpu-used 0 should be much faster than best at a minimal  quality loss
[22:04:25 CET] <smarter> there's no point
[22:04:32 CET] <smarter> exactly
[22:04:50 CET] <atomnuker> turns out I hadn't even set -b:v
[22:05:06 CET] <atomnuker> I get 0.2x realtime now
[22:05:10 CET] <atomnuker> pretty decent
[22:05:38 CET] <atomnuker> still only 1 thread though
[22:05:57 CET] <nevcairiel> didnt they introduce some sort of slice threading
[22:18:59 CET] <Daemon404> i keep hoping theyll fix RC
[22:19:08 CET] <Daemon404> but every member of teh vp9 team i talked to said its a non-issue
[22:19:11 CET] <Daemon404> not even on their TODO
[22:31:43 CET] <llogan> we could use a vp9 encoding guide on wiki
[22:31:55 CET] <c_14> llogan: there is one
[22:32:17 CET] <c_14> Might need updates though
[22:32:27 CET] <c_14> https://trac.ffmpeg.org/wiki/Encode/VP9
[22:32:50 CET] <llogan> oh, duh
[22:34:03 CET] <llogan> is that an orphaned page?
[22:35:02 CET] <llogan> what use is this? https://trac.ffmpeg.org/wiki/NullRenderer
[22:35:59 CET] <llogan> yet another of Roger's Ramblings"
[22:36:56 CET] <J_Darnley> I was wondering whether you mean "what use is this page" or "what use is -f null" :)
[22:37:13 CET] <llogan> i use null often
[22:49:38 CET] <Daemon404> everyone does
[22:58:38 CET] <beastd> -f null is quite useful :)
[22:59:16 CET] <beastd> though i could use -f lol from time to time ;-)
[23:13:20 CET] <atomnuker> hm, the mp3float decoder is 2x (500xrealtime) the speed of mp3 (~250xrealtime)
[23:13:59 CET] <kierank> probably simd
[23:15:28 CET] <wm4> I always wondered what was the difference between them
[23:17:35 CET] <atomnuker> I think it'd be nice to have mp3float made default on x86
[23:17:46 CET] <atomnuker> since currently mp3 is the default
[23:18:08 CET] <BBB> llogan: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide
[23:18:17 CET] <BBB> llogan: (its all ffmpeg stuff)
[23:29:22 CET] <llogan> BBB: thanks
[23:29:35 CET] <llogan> "FFMpeg"
[23:36:12 CET] <durandal_170> atomnuker: you really writting showspectrumpic?
[23:37:06 CET] <durandal_170> ubitux: showspectrum is missing overlap for big fft size
[23:41:08 CET] <atomnuker> why, do you want to do it?
[23:43:38 CET] <atomnuker> if you do, then go ahead, it would probably take me much longer
[00:00:00 CET] --- Tue Dec 29 2015