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

[burek]

[00:00] <ubitux> ok
[00:00] <ubitux> this all sounds overcomplicated for no good reason though
[00:00] <rcombs> indeed!
[00:03] <rcombs> and unfortunately, I think Pango is probably too high-level for libass
[00:04] <J_Darnley> ubitux: there is still only the log2_chroma_[wh] values rather than a value per component.  This means that you need to do "tricky" things for >3 planes or if you want a loop that includes the luma plane.
[00:05] <ubitux> >3 planes? alpha channel?
[00:05] <J_Darnley> yes.
[00:06] <J_Darnley> I don't recall anything with a 5th plane yet
[00:07] <ubitux> let's add a plane for subtitles
[00:08] <J_Darnley> z-data, to support a 3d volume!
[00:09] <rcombs> one plane for each cone type in a mantis shrimp's retina!
[00:09] <rcombs> (we're going to need a bigger Bayer filter)
[00:17] <J_Darnley> okay, that looks like it is working.
[00:30] <thardin> I did those very low bitrate video tests btw
[00:31] <thardin> x265 is looking very promising :)
[00:32] <thardin> and version string does indeed mess up rate control at these low rates
[00:43] <J_Darnley> ubitux: I'm going to send a WIP to the list so you, and everyone else, can see it.
[00:43] <J_Darnley> It works but is missing a few things.
[00:43] <J_Darnley> like some documentation.
[01:27] <Timothy__Gu> J_Darnley: CMYKA has 5 planes
[01:29] <Timothy__Gu> Interesting English: "Why to crash, if don't crash it's better? :)" in #3950
[01:46] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:6beea6f017f5: avcodec/tiff: fix odd dimensioned yuv
[03:13] <cone-583> ffmpeg.git 03James Almer 07master:91459bd320b4: avcodec: remove obsolete FF_API_DSPUTIL cruft
[05:32] <molikto_> hi, i know this is offtopic... but can anyone help me configure a minimal build for some specific input/output/command??? I am helpless and the only thing in my mind is to try divide and conquer....
[05:35] <molikto_> anyone here?
[06:20] <molikto_> anyone can help me??
[06:25] <jamrial> molikto_: this channel is for development of ffmpeg. for user support you should ask in #ffmpeg
[06:26] <molikto_> the question is not exactly a user-level question... although it is also not dev-related... nevermind... i will figure out myself
[07:21] <ubitux> ff
[07:21] <ubitux> oups
[08:30] <sorinv> Hey guys .. quick question: do you know where this kind of error comes from? I am struggling to build Blender with ffmepg support in it getting this link error
[08:30] <sorinv>  /opt/lib/ffmpeg/lib/libavcodec.a(libtheoraenc.o): In function `submit_stats':
[08:30] <sorinv>  /root/src/blender-deps/ffmpeg-2.1.5/libavcodec/libtheoraenc.c:142: undefined reference to `th_encode_ctl'
[11:15] <wm4> ubitux: still working on that subtitle thing?
[11:16] <ubitux> yes, but today i'm at work :p
[11:16] <wm4> in mpv I have some kind of subtitle "filter chain"
[11:16] <wm4> but it's not very good and has some design issues
[11:16] <ubitux> wm4: WIP @ https://github.com/ubitux/FFmpeg/compare/subtitles-ng
[11:17] <ubitux> WIP commit is basically a draft i started yesterday as an attempt to create a text sub structure for the decoded form, with ass markup, as muxed in mkv
[11:18] <wm4> hm
[11:19] <ubitux> tell me more about your subtitle filter chain
[11:19] <wm4> it passes the mpv equivalent of AVPacket from filter to filter
[11:19] <wm4> and filters at the end of the chain have a function for retrieving bitmaps
[11:20] <wm4> subtitle converts (like lavc "decoders") are filters in the middle of the chain
[11:20] <wm4> renderers are at the end
[11:20] <wm4> one renderer is libass, and the other is lavc (for vobsub and pgs)
[11:21] <wm4> but things like charset conversion or timing adjustments (avoiding small gaps/overlaps) are unfortunately not part of the chain
[11:22] <wm4> but it would be nice if a new ffmpeg subtitle api could handle these things
[11:27] <ubitux> hum
[11:28] <ubitux> the charset convert model is so broken in ffmpeg you can't use it?
[11:29] <ubitux> what's this timing adjustment? for post seeking?
[11:29] <wm4> ffmpeg just wraps iconv a little, it's utterly unusable
[11:30] <wm4> the timing adjustment is just to avoid little gaps of no subs, or subs overlapping for a moment
[11:30] <wm4> because of timing inaccuracies
[11:30] <wm4> it's not used for ASS
[11:36] <ubitux> i'm not sure what to propose for charsets..
[11:36] <ubitux> grr we really need that timeline thing for mov/mp4
[11:37] <wm4> isn't that similar to mkv ordered chapters?
[11:39] <ubitux> dunno
[11:48] <ubitux> wm4: btw, hb can be built without glib in the upstream
[11:49] <wm4> I know
[11:49] <wm4> but distros use glib anyway
[13:47] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:8c1dc1f6ed11: avformat/network: add union for avoiding strict aliassing violations with sockaddr*
[13:47] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:e587a428d75d: avformat/rtpproto: fix strict aliasing violations with sockaddr
[14:07] <ubitux> anyone has a link to the previously rejected mov edit list patch from google?
[14:16] <ubitux> michaelni: n2.5-dev LGTM
[14:17] <iive> 2.4 have been release?
[14:17] <iive> d
[14:18] <ubitux> yes
[14:21] <iive> nice :)
[14:30] <wm4> seriously how did this ever happen: vf_eq and vf_eq2
[14:30] <wm4> they use the same asm
[14:30] <wm4> at least almost
[14:31] <wm4> or actually it's exactly the same
[14:31] <J_Darnley> You are probably right with your "politics" comment.
[14:31] <ubitux> :D
[14:34] <iive> wm4: there are eq and eq2 native ffmpeg filters?
[14:34] <wm4> no, libmpcodecs
[14:35] <iive> oh, ok.
[14:43] <iive> wm4: what is the trouble with vdpau and preemption, and what kind of preemption is at play there?
[14:45] <wm4> iive: vdpau preemption can lose the vdpau state at any time (typically VT switching)
[14:47] <iive> so you have to restart decoding from scratch?
[14:49] <wm4> basically; you have to reinitialize everything again
[14:51] <iive> major headache...
[14:51] <iive> does this apply to the mesa3d gallium vdpau driver too?
[14:53] <wm4> no
[14:53] <wm4> apparently not
[14:53] <wm4> just nvidia
[15:28] <nevcairiel> you know its fasctinating how just days after a change lands in ffmpeg, the same change lands on the libav ML, but they didnt bother to keep authorship. Granted, its just a trivial one line change, but still, and don't even try to claim coincendence
[15:28] <nevcairiel> -n
[15:29] <wm4> don't let them hear that
[15:49] <ubitux> nevcairiel: what are you thinking about?
[17:01] <J_Darnley> I'm now wondering why contrast seems to have a different meaning and default in eq2.  The default has moved from 0 to 1.0 and it seems to lack an add when it is used (in the mmx function).
[17:01] <J_Darnley> (I'll read any replies later, I need to make dinner)
[17:10] <iive> J_Darnley: hum? brightness and contrast form liner function where output=brightness+contrast*input.
[18:10] <cone-192> ffmpeg.git 03James Almer 07master:4ae6bcc025e7: RELEASE: update to 2.4.git
[20:15] <J_Darnley> Dammit!  Why are you giving me a grey image?
[20:16] <nevcairiel> grey ios the new black?
[20:16] <J_Darnley> :)
[20:24] <J_Darnley> dammit gdb!  why can't you give ffmpeg a filename with spaces?
[20:24] <ubitux> gdb --args ?
[20:25] <wm4> gdb --args ./ffmpeg "fi le.mkv"
[20:25] <J_Darnley> Doesn't work.  gdb still seems to split at the space despite there being a backslash
[20:26] <ubitux> shell issue?
[20:26] <wm4> are you on windows?
[20:26] <J_Darnley> Cygwin and bash
[20:26] <wm4> windows treats the command line as a single string, instead of a list of arguments
[20:26] <wm4> so you'll get random fuckups there
[20:28] <J_Darnley> gdb is probably doing something special here
[20:28] <J_Darnley> rather than what every other program does
[20:38] <wm4> well, gdb has to pass the arguments to the child process
[21:01] <cone-192> ffmpeg.git 03James Almer 07master:af7d2606261e: avutil: remove obsolete FF_API_LLS1 cruft
[21:01] <cone-192> ffmpeg.git 03James Almer 07master:95a064f53034: avutil: remove obsolete FF_API_OLD_OPENCL cruft
[21:01] <cone-192> ffmpeg.git 03James Almer 07master:ad1dadac86d4: avfilter: remove obsolete FF_API_BUFFERSRC_BUFFER cruft
[21:02] <J_Darnley> Is the AVOption system supposed to initialize unspecified options as the default values?
[21:04] <nevcairiel> yes
[21:04] <nevcairiel> if something called the set-defaults function on your context
[21:05] <J_Darnley> maybe I'm missing that.
[21:05] <nevcairiel> usually you wouldnt need to do that yourself, unless you invented some kind of new context
[21:13] <J_Darnley> oh nevermind, i'm just an utter idiot
[21:30] <J_Darnley> There we go.  eq and eq2 are now in one file.
[21:33] <wm4> yay
[21:42] <ubitux> in vf_hue.c ?
[22:01] <J_Darnley> no.
[22:31] <cone-192> ffmpeg.git 03Mika Raento 07master:f685f7d7a838: hlsenc: single_file, support HLS ver 4 byteranges
[22:40] <cone-192> ffmpeg.git 03Mika Raento 07master:00431bf874e1: ismindex: handle time discontinuities and nonzero start time
[22:40] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:21561610560f: Merge commit '00431bf874e1044b01e09a2266ef85d4ff8d44cc'
[23:26] <iive> "[h264 @ 0xb5204440] non-existing SPS 32 referenced in buffering period" what does this message mean?
[23:26] <nevcairiel> it tries to use a SPS which it doesn't have yet
[23:26] <iive> it's spamming my console when i play dvb-t stream.
[23:26] <nevcairiel> if the message occurs during opening of the file, it can usually be safely ignored
[23:27] <nevcairiel> how does playback look?
[23:27] <iive> perfect.
[23:27] <nevcairiel> and it keeps spamming the message during playback?
[23:27] <iive> yes
[23:27] <nevcairiel> thats weird
[23:28] <nevcairiel> but as long as playback works!
[23:29] <iive> it's horrible
[23:29] <wm4> oh, libav having a flame about their review policy
[23:29] Action: wm4 gets popcorn
[23:30] <nevcairiel> and not even one of us that started it
[23:31] <iive> funny thing, when ffplay reaches the end of the playback, the messages start to get grouped 200-300 together.
[23:32] <iive> wm4: irc or maillist?
[23:32] <wm4> irc
[23:32] <nevcairiel> irc
[23:33] <ubitux> i thought i was the only one to notice an hour ago
[23:34] <ubitux> seems i'm not the only evil stalker
[23:34] <nevcairiel> i mostly ignored it
[23:34] <nevcairiel> its nothing but all the same
[23:36] <ubitux> wm4: u evil
[23:40] <ubitux> haha he's trolling hard
[23:40] <wm4> courmisch threatening to fork
[23:40] <ubitux> for the third time
[23:40] <iive> wm4: remi? the one with the vdpau patches i asked about?
[23:40] <ubitux> yes
[23:40] <iive> what a coincidence...
[23:41] <baptiste> courmisch in libav ? 
[23:42] <j-b> yeah
[23:42] <nevcairiel> its not like he would run a full fork, more like my fork, application specific patches on top of upstream
[23:42] <nevcairiel> many downstreams have such things
[23:43] <nevcairiel> just not those trying to be  d istributed on linux
[23:43] <ubitux> it's probably a way to get it merged in ffmpeg without being explicit sending it to ffmpeg-devel
[23:44] <j-b> And not a bad tactics
[23:45] <ubitux> i'm not exactly sure what would be the point of doing so, except :ego:
[23:45] <ubitux> but sure, if it works, whatever :)
[23:45] <baptiste> j-b, why not sending to both ?
[23:45] <wm4> or just fork and relicense as GPL3
[23:46] <j-b> baptiste: no clue.
[23:46] <j-b> baptiste: probably because it's eaiser to send to one?
[23:48] <nevcairiel> well if you want to rely on some new API, you kinda need to send it to libav, or it wont be available on a bunch of systems, and since ffmpeg merges anyway..
[23:48] <baptiste> yeah I guess adding another cc is more complicated ;)
[23:49] <wm4> btw. did the debian ffmpeg package make it yet?
[23:49] <nevcairiel> the dude  said in a mail earlier today it might get in soon
[23:49] <wm4> soon? ok, I'll ask again in 6 months
[23:49] <nevcairiel> baptiste: if the api needs changing d ue to feedback, its better not to have it merged in one project already, but wait until its actually finished
[23:49] <ubitux> it can, because it's in the top 5 pending packages
[23:50] <ubitux> (if you count the 4+ months in queue before version bump)
[23:51] <iive> is the queue visible somewhere?
[23:51] <ubitux> https://ftp-master.debian.org/new.html
[23:51] <iive> i kind of get the feeling it is more like a blackbox...
[23:51] <ubitux> 2.2.1 waited 4+ months, 2.3.1 waited 1+ month, 2.4 was submitted... an hour ago
[23:51] <ubitux> actually, 3
[23:52] <baptiste> nevcairiel, in my experience, getting any feedback as early as possible is better, but it's true that I haven't sent a patch since quite some time :)
[23:55] <cone-192> ffmpeg.git 03Clément BSsch 07master:864d124bb7aa: build: simplify libwebp check
[23:58] <iive> baptiste: it is nice to see you around.
[00:00] --- Tue Sep 16 2014