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

[burek]

[02:44] <durandal_1707> lol i found what BRSTM stands for by accident
[02:51] <llogan> durandal_1707: dispell my ignorance
[02:52] <tg2> hey
[02:52] <llogan> hej
[02:52] <tg2> is there any easy way to get ffprobe to output only I frames?
[02:52] <tg2> without parsing through grep
[02:54] <tg2> --show-frames scans for and shows all frames, audio and video, however I only need pict_type I frames
[02:55] <tg2> just modify show_frame in ffprobe.c?
[02:55] <tg2> or is there a more efficient way
[02:58] <durandal_1707> llogan: what is ^
[02:59] <llogan> durandal_1707: an article about frameserving from premiere to ffmpeg because Adobe Media Encoder is butt.
[02:59] <llogan> also, you never told me what BRSTM is and I'm too lazy to search
[02:59] <durandal_1707> Binary Revolution Stream
[02:59] <llogan> ah
[03:00] <llogan> ...but first i will have to motivate myself to use the windows partition.
[03:01] <tg2> adobe dilemma
[03:02] <llogan> and i already found a typo
[03:59] <cone-819> ffmpeg.git 03Michael Niedermayer 07407921072f6d: file: fix file_check()
[05:08] <cone-819> ffmpeg.git 03Michael Niedermayer 07465becbc4f1f: configure: check for access()
[05:08] <cone-819> ffmpeg.git 03Michael Niedermayer 0716ef48c37fad: file: Fallback to stat() based file_check() when access() or its named flags are unavailable.
[05:08] <cone-819> ffmpeg.git 03Michael Niedermayer 078aa6d899c01f: cafdec: fix seeking with adpcm
[08:28] <burek> does this look like an acceptable layout for the fate html page: http://ffmpeg.gusari.org/fate/
[08:29] <burek> (try also hovering the mouse over maintainers) :)
[08:29] <burek> btw, it's pure html + css, without javascript :)
[08:57] <cbsrobot> burek:  I like the avatar of barabra streisand
[08:57] <cbsrobot> where does she live again ?
[09:01] <burek> :)))
[09:01] <burek> somewhere..
[09:01] <burek> over the rainbow i guess :)
[09:44] <llogan> burek: looks pretty good to me. "ffmpeg green" might be nice though but that's an ignore-a-nit
[10:48] <cone-677> ffmpeg.git 03Mark Himsley 0713c625253625: lavfi/overlay: enable yuva420p as overlay background
[11:18] <cone-677> ffmpeg.git 03Paul B Mahol 0710c8f913410e: astdec: improve probing
[11:23] <cone-677> ffmpeg.git 03Paul B Mahol 0751d6879939bf: AFC demuxer
[13:09] <michaelni> burek, looks cool, it lost the ability to sort by clicking on the column header though 
[13:27] <michaelni> burek, also current fate server shows a little black triangle on the main page with every client that has failures, clicking on that reveals more info about the failures
[13:36] <cone-677> ffmpeg.git 03Michael Niedermayer 07257196209fe7: file: fix 10l error in access() check
[13:47] <cone-677> ffmpeg.git 03Mans Rullgard 07dd3b73f3905c: base64: fix signed overflow in shift
[13:47] <cone-677> ffmpeg.git 03Mans Rullgard 07edd80ec7e32b: aacdec: fix signed overflows in lcg_random()
[13:47] <cone-677> ffmpeg.git 03Michael Niedermayer 071e276553886a: aacenc: use the correct output buffer
[13:47] <cone-677> ffmpeg.git 03Justin Ruggles 07284ea790d894: dsputil: move vector_fmul_scalar() to AVFloatDSPContext in libavutil
[13:47] <cone-677> ffmpeg.git 03Michael Niedermayer 072684d2e3ea8a: Merge commit '284ea790d89441fa1e6b2d72d3c1ed6d61972f0b'
[14:14] <cone-677> ffmpeg.git 03Justin Ruggles 07947f933687b9: x86: float_dsp: add SSE version of vector_fmul_scalar()
[14:14] <cone-677> ffmpeg.git 03Diego Biurrun 07d89f2fa970ed: configure: Add separate list for libraries and use where appropriate
[14:14] <cone-677> ffmpeg.git 03Justin Ruggles 073c370f5abc55: riff: only warn on a bad INFO chunk code size instead of failing
[14:14] <cone-677> ffmpeg.git 03Michael Niedermayer 07b4d4e51027e0: Merge commit '3c370f5abc55739a261534b9f9bdc739cedbbbb9'
[14:36] <cone-677> ffmpeg.git 03Justin Ruggles 07259d8c564741: riff: do not add empty metadata tags in INFO chunk
[14:36] <cone-677> ffmpeg.git 03Michael Niedermayer 072fe0094e0bf9: wavenc: write fact chunk sample count at the correct file position
[14:36] <cone-677> ffmpeg.git 03Michael Niedermayer 075d47850bbd9e: dcadec: skip QMF on unused channels
[14:36] <cone-677> ffmpeg.git 03Janne Grunau 07150b2361ca08: h264: add missing new line to log message
[14:36] <cone-677> ffmpeg.git 03Janne Grunau 076e5cdf262819: h264: check ref_count validity for num_ref_idx_active_override_flag
[14:36] <cone-677> ffmpeg.git 03Michael Niedermayer 07577b39aea221: Merge commit '6e5cdf26281945ddea3aaf5eca4d127791f23ca8'
[14:41] <cone-677> ffmpeg.git 03Janne Grunau 07d5e83122bdc3: h264: set Picture.owner2 to the current thread
[14:41] <cone-677> ffmpeg.git 03Michael Niedermayer 074063bb212e18: Merge remote-tracking branch 'qatar/master'
[15:06] <cbsrobot> burek: No! See http://en.wikipedia.org/wiki/Streisand_effect
[16:00] <ubitux> if we want to play streams from different files, i guess we have to keep track of multiple AVFormatContext, right?
[16:00] <ubitux> or is there another trick?
[16:04] <vdurand> Hi. My question concerns HE-AAC decoding in ffmpeg. It is currently too CPU intensive to work smoothly on fixed-point architectures in embedded devices. The Fraunhofer SDK provides a fixed-point implementation that proves much more efficient. Since ffmpeg 1.0, Fraunhofer is used for aac encoding. Is there any reason to not use it for aac decoding?
[16:05] <JEEBsv> you can't distro binaries with it
[16:05] <JEEBsv> that's all
[16:05] <JEEBsv> I'm not sure about LGPL, but its license is not compatible with GPL (if you, f.ex. have libx264 in there)
[16:06] <JEEBsv> in any case, it seems to need --enable-nonfree with both LGPL and GPL
[16:06] <JEEBsv> (the only reason why it's not GPL-compatible is because it adds the additional definition that you can't take money for things with it, which GPL doesn't prohibit)
[16:08] <vdurand> I see. I'll need to review its license. Do licenses apply differently for encoding and decoding?
[16:08] <JEEBsv> no
[16:09] <JEEBsv> vdurand: license is over @ https://github.com/mstorsjo/fdk-aac/blob/master/NOTICE
[16:09] <vdurand> Then I don't get why ffmpeg uses Fraunhofer for encoding and not decoding
[16:09] <cone-677> ffmpeg.git 03Michael Niedermayer 07c2c1726847fe: ffserver remove CONFIG_NOCUTILS check
[16:10] <JEEBsv> because no-one wrote a decoder that uses the library? And because the libavcodec AAC decoder in general is in much better standing than the internal encoder
[16:12] <vdurand> OK thanks. I'm about to integrate Fraunhofer into ffmpeg for aac decoding, hence my questions.
[16:13] <JEEBsv> it's really sad that fraunhofer had to write their own license, which was pretty much GPL, but then not exactly :P
[16:13] <JEEBsv> and that "not exactly" then makes it GPL-incompatible because it doesn't limit you in taking money from the software, while the fraunhofer license does
[16:57] <Daemon404> nevcairiel, where did you get LAVF_DISPOSITION_SUB_STREAM from
[16:57] <Daemon404> MagicNumbers(TM)
[16:59] <Daemon404> hmmm only for audio
[16:59] <Daemon404> guess its not my problem
[17:36] <nevcairiel> Daemon404: thats my own definition :p
[17:36] <nevcairiel> i even used a special prefix!
[17:37] <Daemon404> i see it
[17:38] <nevcairiel> it also just flags the embeded ac3 stream
[17:38] <Daemon404> yeah i sae
[17:38] <Daemon404> saw
[17:38] Action: Daemon404 is adding pid switching
[17:38] <nevcairiel> sounds like fun
[17:38] <Daemon404> now if only i could figure out why teh 2nd pid plays linearly but crashes
[17:38] <Daemon404> :V
[17:39] <Daemon404> while seeking
[17:39] <JEEBsv> * Daemon404 is adding pid switching <- zomg
[17:40] <Daemon404> JEEBsv, for d2vsource
[17:40] <Daemon404> dont get your hopes up
[17:40] <JEEBsv> :<
[17:40] <JEEBsv> looked how marumo's does it?
[17:40] <Daemon404> no
[17:40] <Daemon404> because there are no comments
[17:40] <JEEBsv> k
[17:41] <Daemon404> or theyre in jp
[18:17] <cone-677> ffmpeg.git 03Michael Niedermayer 0793b89868e139: h264: support invalid annex B in mp4
[20:09] <cone-677> ffmpeg.git 03Paul B Mahol 07761aba6811ba: fate: add ADPCM IMA Dialogic OKI decoder test
[20:12] <Daemon404> durandal_1707, did you ever hear back from the tak dev?
[20:12] <Daemon404> re: his pascal source
[20:12] <durandal_1707> not (yet)
[20:13] <Daemon404> might be the lazy way to add coding type 0 support
[20:14] <durandal_1707> Daemon404: what happened with your uscaled rgb<- (?) ->gbrp ?
[20:15] <Daemon404> its still sitting on the mailing list
[20:15] <Daemon404> waiting for me to be unlazy and implement the ugly YUV path
[20:15] <Daemon404> which swscale requires
[20:15] <Daemon404> (you cant have only an rgb<->rgb path)
[20:16] <durandal_1707> does it works for rgb->gbrp if you do not set output for gbrp?
[20:17] <durandal_1707> there should be unscaled rgb<->gbrp path but it may be blocked by stupid dependency on yuv -> gbrp path
[20:17] <Daemon404> yes
[20:17] <Daemon404> it's exactly that
[20:17] <Daemon404> there is no yuv->bgrp path
[20:17] <Daemon404> my patch only adds rgb->gbrp
[20:18] <durandal_1707> but it still should work if output flag is not set for gbrp
[20:19] <durandal_1707> michaelni: ^ similar is with rgb48->rgb64
[20:20] <ubitux> (funny patches incoming!)
[20:21] <cone-677> ffmpeg.git 03Michael Niedermayer 07de9fc0e9d67e: mjpegdec: make sure ret is set before its used.
[20:21] <cone-677> ffmpeg.git 03Michael Niedermayer 071c16483cc0da: mjpegdec: replace returns by goto fail in frame decode.
[20:21] <cone-677> ffmpeg.git 03Michael Niedermayer 07541efe4120bd: mjpegdec: reset got_picture on errors, successful return, init and flush.
[20:21] <cone-677> ffmpeg.git 03Michael Niedermayer 072cfa6fd025f7: mjpegdec: dont set got_picture to 0 per frame.
[20:21] <ubitux> (not yet ready though)
[20:25] <durandal_1707> ubitux: ?
[20:26] <ubitux> i added the support for text subtitles in ffplay :p
[20:26] <ubitux> (muxed & external)
[20:26] <ubitux> seems to work, mostly
[20:26] <ubitux> i get duplicated events sometimes though
[20:34] <durandal_1707> ubitux: l is removing slicify filter
[20:34] <ubitux> i saw that
[20:35] <ubitux> i have no particular opinion
[20:35] <ubitux> the simplification looks appealing like every simplification, and i didn't check the no-performance-benefit assertion 
[20:35] <ubitux> s/and/but/
[20:37] <ubitux> we will have to update all our filters though
[20:38] <wm4> removing slices from lavfi or what?
[20:39] <ubitux> wm4: yes
[20:40] <wm4> but what about UNCOMPROMISED PERFORMANCE
[20:40] <Daemon404> orite
[20:40] <Daemon404> that reminds me
[20:40] <Daemon404> i remember you guys pimping lavfi because 'it can direct render'
[20:40] Action: Daemon404 added direct render support for lavc to his vapoursynth plugin =p
[20:41] <ubitux> wm4: as i said, i haven't benchmarked, and i have no opinion on the matter, except that the simplification looks appealing
[20:41] <wm4> I wonder why libavcodec can't do buffer management on its own
[20:41] <wm4> instead it's messed into cmdutils.c
[20:42] <Daemon404> a lot of the 'interesting' logic is in cmdutils or ffmpeg.c
[20:42] <Daemon404> News at 11
[20:46] <durandal_1707> when should i add new codec and do not abuse demuxer?
[20:47] <michaelni> wm4, libavcodec can and does, but if you want it to use your buffers you have to provide callbacks to allocate and release them
[20:48] <durandal_1707> there is format that packs 10 24bit samples into 32 bytes
[20:48] <wm4> michaelni: I think the use case where you just want to keep a decoded image around for a while is the most common
[20:49] <wm4> michaelni: for that, the current interface is complicated and messy, and right now you even have to work around decoder bugs (see cmdutils.c)
[20:50] <wm4> michaelni: it'd be much more useful if libavcodec just gave the user a buffer of a decoded image, and a function to give it back to libavcodec again
[20:54] <michaelni> wm4 that shouldnt be hard to implement
[20:55] <wm4> well, consider it a feature request :)
[20:58] <saste> wm4, consider it a "patch welcome" ;-)
[20:58] <nevcairiel> i heard rumors anton was working on reference counting for avframes, or was that avpackets.. i forget
[20:59] <ubitux> saste: i see no av_free_packet() in doc/examples/demuxing.c; is this normal?
[20:59] <saste> ubitux, maybe, or maybe not
[20:59] <durandal_1707> nevcairiel: hmm, what about switching to c++ ?
[21:00] <saste> durandal_1707, no, let's designa new language
[21:00] <ubitux> based on ffmpeg eval()?
[21:01] <durandal_1707> web
[21:11] <durandal_1707> bunch of mp3 failures recently
[22:12] <ubitux> now vobsub subtitles are gonna get ugly
[22:14] <wm4> does anyone know how vobsubs are positioned over the video?
[22:15] <nevcairiel> they have x/y coordinates in the bitstream, how else? :d
[22:16] <nevcairiel> the only problem is that it doesnt come with a video frame size in the bitstream, so you either need to guess that (based on the video stream that comes with it), or have a vobsub index file with that info
[22:17] <wm4> I know
[22:17] <wm4> and then there's the question how anamorphic video is handled in the first place (my own attempts of testing anamorphic DVD rips with vobsubs embedded give a "stretched" result)
[22:18] <wm4> (still slightly better what mplayer/mplayer2 do right now, though)
[22:19] <nevcairiel> the most annoying part about vob subs is that the bitstreams fails to carry a palette, so if you just open a .vob file, you get ugly ugly subs
[22:44] <saste> ubitux: subtitles rendering in ffplay, yeah :)
[22:44] <ubitux> :D
[22:45] <ubitux> i think it's going to get a bit hacky when i'll add support for external bitmap subtitles (such as vobsub)
[22:46] <saste> ubitux, this reminds me that nicolas posted a patch for showing subtitles text via ffprobe
[22:47] <saste> it was not committed because ffprobe couldn't support arbitrary section nesting, now it should be fairly possible
[22:47] <ubitux> feel free to nudge him :)
[23:40] <saste> ubitux: i have an updated psnr diff filter in one of my local repo, but it is still incomplete IIRC
[23:40] <ubitux> based on luca's one?
[23:41] <saste> it should have more features than compare
[23:41] <ubitux> the biggest problem with compare was the 10 alloc per frame
[23:41] <saste> no it was based on another filter posted some time ago by roger pau monnè
[23:41] <ubitux> which was -really- stupid
[23:41] <saste> IIRC
[23:41] <ubitux> ok
[23:41] <saste> i can send you psnr if you want to work on it
[23:42] <ubitux> no i don't have time for this sorry
[23:42] <ubitux> but i'm pretty interested in the feature though :)
[23:42] <saste> there was an optimization problem also, it used generic routines but we wanted to implement optimized format-specific ones
[23:44] <cone-624> ffmpeg.git 03Stefano Sabatini 072ac6a3d1bfd0: lavfi/drawtext: add support to expansion of generic expressions
[23:44] <cone-624> ffmpeg.git 03Stefano Sabatini 078ddeae5ae7b8: doc: add libavformat.texi and ffmpeg-formats.texi files
[23:44] <cone-624> ffmpeg.git 03Stefano Sabatini 07d82331721ee6: doc: add libavdevice.texi and ffmpeg-devices.texi files
[23:44] <cone-624> ffmpeg.git 03Stefano Sabatini 079c492271a8e4: doc: move syntax and eval chapters from libavutil to ffmpeg-utils
[23:44] <cone-624> ffmpeg.git 03Stefano Sabatini 073a227f5d9042: doc: add ffmpeg-protocols.texi manual
[23:53] <burek> michaelni, it's sortable now
[23:53] Action: ubitux wonders if he shouldn't wait for the crowd-funding thing before doing true peaks in ebur128
[23:53] <burek> (without page reload)
[23:56] <cbsrobot> ubitux: no
[23:57] <ubitux> cbsrobot: why? :D
[23:57] <ubitux> you want to profit from my work for free?! you evil!
[23:58] <ubitux> :))
[23:58] <cbsrobot> well I do not want you to think about it too much 
[23:58] <ubitux> well i should have time for this pretty soon anyway
[23:58] <cbsrobot> ubitux: sure and become a millionair
[23:58] <burek> llogan, if you could provide a sample screen shot of "ffmpeg green" that would be great :)
[23:59] <burek> cbsrobot :))) +1
[23:59] <michaelni> burek, the sorting is cool
[00:00] --- Wed Nov 28 2012