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

[burek]

[00:00] <saste> and work a bit on the gsoc page
[00:00] <llogan> i'll try to work on the ideas page over the weekend.
[00:02] <saste> good
[00:25] <Compn> saste : can you put the generated doc/html online so i can look at it ?
[00:25] <ubitux> would be nice to have a power of two constraints as flag option
[00:25] <Compn> :P
[00:25] <Compn> or just email/dcc it
[00:26] <saste> Compn, I'll email it
[00:27] <saste> basically it is the same as the usual docs, but at the end it contains various sections utils, resampler, rescale, formats, codecs, devices, filters, bitstream-filters and protocols
[00:27] <saste> Compn, or alternatively i can push a branch on gitorious
[00:28] <saste> but the problem is mainly related to the design and to how to integrate in the webserver
[00:28] <saste> since we want to show two links for each tool (slim and fat page)
[00:31] <saste> ubitux, do you mind if i create your user page?
[00:31] <Compn> saste : oh, just throw a link to the complete ffmpeg documentation page
[00:32] <Compn> under all the other links :)
[00:32] <saste> Compn, there is no such thing
[00:32] <Compn> hmm?
[00:32] <saste> there is the ffmpeg (and ffprobe, ffplay, ffserver) manual pages with complete submodule docs
[00:33] <Compn> oh
[00:33] <Compn> then four links :)
[00:33] <saste> ffmpeg is not special with regards to the other tools
[00:33] <ubitux> saste: np go ahead
[00:33] <ubitux> saste: just make sure to obfuscate the mail if you want to put it
[00:34] <saste> ubitux, i'm not adding emails, just the irc nick and few note (an ffmpeg dev blah blah)
[00:34] <saste> i suggest to put the (obfuscated) email so a student can find it more easily, but i leave that to the single mentor
[01:11] <llogan> saste: what about submitting the application as a mm wiki page? might be easier to amend and keep it up to date.
[01:12] <llogan> unless you want to "hold your cards close"
[01:13] <saste> llogan, we can create a template on the wiki for similar projects (gsoc, socis)
[01:13] <saste> but then the application is done via a form
[01:13] <saste> i have to fill it by hand
[01:13] <llogan> oh.
[05:02] <cone-156> ffmpeg.git 03Michael Niedermayer 07master:4c1f61b1e879: ffmpeg: Correct inter stream timestamp discontinuities
[05:08] <ubitux> some more pts magic ._.
[05:15] <Daemon404> ...
[05:15] <Daemon404> youre doing that /in the cli/?
[05:15] <Daemon404> thats bullshit.
[05:15] <Daemon404> do it in a filter proper
[05:16] <Daemon404> as libav does
[05:16] <Daemon404> (iirc)
[05:27] <ubitux> decimate filter is going to be harder than expected :p
[05:54] <michaelni> Daemon404, libav does not, and i suggest you check the code before saying X does this Y does that
[05:56] <michaelni> besides, write more code, troll less, if you have a better solution implement it iam very happy to replace code by better code
[05:57] Action: michaelni goes to afk (sleeping)
[05:57] <Daemon404> should really be in a filter like asyncts/aresample
[05:57] <Daemon404> all of the vsync stuff
[05:58] <Daemon404> like audio stuff is
[05:58] <Daemon404> i dont know how pointing out obvious bad practice is considered trolling.
[05:59] <michaelni> its not possible in async or vsync filter, its _BETWEEN_ streams, aka you need all streams 
[06:00] <michaelni> its trolling because either A. i ignore it and leave these false statements that sound correct on a first look or i spend time correcting
[06:00] <michaelni> thats wasting time
[06:01] <Daemon404> timestamp discontinuities are indeed handled in a filter for audio
[06:01] <Daemon404> and a for sync betwene streams
[06:01] <Daemon404> yeah thats a sore point
[06:02] <Daemon404> since all of teh ACTUALLY USEFUL code is hidden in teh dman cli utils
[06:02] <Daemon404> and to do anything useufl, you gotat read their code and RE the black magic
[06:02] <Daemon404> ask anyone thats had to use the libs
[06:02] <Daemon404> i speak as a heavy downstream user.
[06:03] <ubitux> if that code is is in lavfi you won't use it anyway ;)
[06:03] <Daemon404> true enough
[06:03] <Daemon404> but thats me
[06:03] <Daemon404> doesnt make my point less valid
[06:04] <ubitux> i wouldn't have having more ts magic in lavf instead of the cli thought; but since i don't get a clue about what all this code is about and what problems it tries to solve, i'd better shut up :p
[06:04] <ubitux> wouldn't *mind* having
[06:04] <michaelni> Daemon404, i see the problem with it being in ffmpeg*c, it could be moved elsewhere ...
[06:05] <Daemon404> fwiw
[06:05] <michaelni> but atm i will move to my bed and sleep, we can discuss this tomorrow :)
[06:05] <Daemon404> ok
[06:06] <Daemon404> also i didnt realize lavfi could not handle both audio and video at once
[06:06] <ubitux> ??
[06:06] <Daemon404> [00:59] < michaelni> its not possible in async or vsync filter, its _BETWEEN_ streams, aka you need all streams
[06:06] <Daemon404> ^
[06:06] <ubitux> you can have a filter taking all streams at once
[06:07] <Daemon404> so then it is possible?
[06:07] <ubitux> it's going to be painful to configure though
[06:07] <Daemon404> heh
[06:07] <Daemon404> well wouldnt a filter be a "better" idea than putting it in lavf
[06:07] <Daemon404> re: timestamo magic
[06:07] <ubitux> something like [0:0][0:1][0:2][0:3] bla=vaaa
[06:07] <Daemon404> im thinking from a library perspective
[06:07] <ubitux> but yeah i guess we can imagine such filter
[06:08] <Daemon404> async is already offloaded to lavfi
[06:08] <Daemon404> i think.
[06:08] <ubitux> yes, in the resample though
[06:09] <Daemon404> i imaged a simimar video filter, and some code to handle inter-stream sync
[06:09] <Daemon404> using those 2
[06:09] <ubitux> though, i'm not that fond of pts thing in lavfi
[06:09] <ubitux> because it forces transcode
[06:09] <ubitux> while ts are at format level
[06:09] <ubitux> this sucks a bit (especially when dealing with setpts or such)
[06:10] <Daemon404> there are some cases where you must
[06:10] <Daemon404> e.g. dropping frames
[06:10] <Daemon404> but i see what you mean
[06:10] <Daemon404> lavf seems liek a kudly place to put it too though
[06:10] <Daemon404> kludgy*
[06:10] <ubitux> this brings us to https://ffmpeg.org/trac/ffmpeg/ticket/2350
[06:11] <Daemon404> i see no reason why lavfi has to force a transcode
[06:11] <Daemon404> technically.
[06:11] <Daemon404> ofc given its internals
[06:11] <Daemon404> it may be painful.
[06:12] <ubitux> mmh now that we have the AVFrame things
[06:12] <ubitux> it might indeed be possible to avoid transcode
[06:12] <Daemon404> The Evil Plan
[06:12] <ubitux> maybe i should rename the ticket
[06:12] <ubitux> well whatever
[06:13] <ubitux> got some decimate shit to finish right now
[06:13] <Daemon404> and
[06:13] <Daemon404> re: code more
[06:13] <Daemon404> i have a half working patch for NSS support
[06:13] <Daemon404> that i should finish
[06:13] <Daemon404> True LGPLv2 SSL
[06:14] <Daemon404> aside: NSPR and NSS and Mozilla in general have horrible APIs
[06:14] <ubitux> why don't you write some nice filter for us btw?
[06:14] <ubitux> :D
[06:14] <ubitux> you could port RemoveGrain
[06:15] <Daemon404> id rather port something that doesnt entail REing
[06:15] <Daemon404> and to VS
[06:15] <ubitux> even the first line of that code is actually magic
[06:15] <Daemon404> i tend to not write entangled code for VS, so it would just be a matter of switching the plugin frontend
[06:16] <Daemon404> im not sure anything useful + not 99% asm that needs porting
[06:16] <Daemon404> if you know one, do tell.
[06:16] <ubitux> is the removegrain filter good for anything anyway?
[06:16] <Daemon404> QTGMC makes use of it
[06:16] <Daemon404> is basically its use
[06:16] <Daemon404> MVTools also needs porting
[06:16] <Daemon404> but it's full of evil
[06:17] <Daemon404> for example it uses the audio stream to pass MVs
[06:17] <Daemon404> as its own global state
[06:17] <ubitux> better motivate some ppl to write directly some new better awesome filters
[06:17] <Daemon404> i wonder if you could like
[06:17] <Daemon404> rip a part of blender out for motio tracking
[06:17] <Daemon404> instead of mv tools
[06:19] Action: Daemon404 should also release his foss replacement for msu vqmt
[07:31] <Daemon404> if someone sees saste tomorrow, let him know i will review all of his pendiing patches wrt docs when i wake up tomorrow (read: noon)
[08:24] <ubitux> siretart: 840ecc9e075a0268884141eb25e4f2dc3f35d9dc
[08:25] <ubitux> well, ok, that is starting to get old.
[08:30] <siretart> ubitux: ?
[08:30] <siretart> oh right, I missed some cleanups. thanks for pointing that out
[08:32] <ubitux> as usual, you guys should really have a look to what's in ffmpeg first
[08:32] <nevcairiel> thats no use, they have to re-write the patch anyway, or it wont be accepted
[08:34] <siretart> ubitux: thanks for caring so much how I invest my time
[08:40] <ubitux> siretart: the idea is that we're going to get your changes; so if you could avoid to do the same mistakes we did years ago when adding the features (and/or adding some), it save us some time as well and everyone will be happy
[08:41] <ubitux> if you re-do our stuff, at least do it better
[08:42] <ubitux> unless you don't care about the quality of your project, it would be wise to look at the mistakes and qualities of what other did
[12:16] <cone-130> ffmpeg.git 03Hendrik Leppkes 07master:1e8b9738fa70: avutil/frame: add all remaining frame properties to av_frame_copy_props
[12:16] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:6efe61486d77: Merge commit '1e8b9738fa70e20967ddb542d2f9d5552fc51ec6'
[12:22] <cone-130> ffmpeg.git 03JindYich Makovi
ka 07master:20a8ee3061e6: af_asyncts: fix compensation and PTS monotonicity
[12:22] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:9bb6504e3bff: Merge commit '20a8ee3061e6d777600c13db731bee3c25878991'
[12:31] <cone-130> ffmpeg.git 03Anton Khirnov 07master:4e33582a0bfa: tscc2: allocate AVFrame properly.
[12:31] <cone-130> ffmpeg.git 03Anton Khirnov 07master:93eaeb024436: FATE: add a tscc2 test.
[12:31] <cone-130> ffmpeg.git 03Janne Grunau 07master:3f15b301fa61: fate: add test for cropping h264 to container dimensions
[12:31] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:8b63eeb6b1c2: Merge remote-tracking branch 'qatar/master'
[12:36] <cone-130> ffmpeg.git 03Thierry Foucu 07master:fcf73f9c011f: Call do_video_stats when duplicating frame
[13:54] <cone-130> ffmpeg.git 03Michael Bradshaw 07master:2a97c5915b8f: Make audio FIFO read/write contracts more strict
[13:54] <cone-130> ffmpeg.git 03Giorgio Vazzana 07master:785b849f1c23: lavd/v4l2: honor previously selected input channel
[15:59] <cone-130> ffmpeg.git 03Piotr Bandurski 07master:e26b066cd8db: libspeex: support ZygoAudio (quality 10 mode)
[16:21] <cone-130> ffmpeg.git 03Bojan Zivkovic 07master:e54eb8db9c19: mips: Optimization of AAC psychoacoustic model functions
[16:28] <Compn> saste : 02:37] <Daemon404> if someone sees saste tomorrow, let him know i will review all of his pendiing patches wrt docs when i wake up tomorrow (read: noon)
[16:31] <Compn> Daemon404 : so you are arguing for a new lavfi to fix timestamps instead of being in cli? werent you arguing before that you didnt like lavfi at all?
[16:31] <Compn> make my brain hurt
[16:32] <Compn> (but seriously i am interested in your change of opinion)
[16:35] <saste> Compn, makes sense
[16:35] <saste> one idea is to move data to the filtering layer
[16:35] <saste> so for example you can fix packet timestamps in a filter
[16:36] <saste> that's better than a pile of application-level hacks
[16:59] <cone-130> ffmpeg.git 03Stefano Sabatini 07master:5373a2a2212b: lavfi/anullsrc: fix format negotiation
[16:59] <cone-130> ffmpeg.git 03Stefano Sabatini 07master:fe2cfd50f041: lavfi/anullsrc: simplify logging code in config_props
[16:59] <cone-130> ffmpeg.git 03Stefano Sabatini 07master:4e8062c2d77f: lavfi/anullsrc: remove extra parentheses
[16:59] <cone-130> ffmpeg.git 03Stefano Sabatini 07master:a42d15a3a0ef: lavfi/anullsrc: add missing checks
[17:41] <Daemon404> [11:31] <@Compn> (but seriously i am interested in your change of opinion)
[17:41] <Daemon404> [...]
[17:41] <Daemon404> [11:35] <@saste> that's better than a pile of application-level hacks
[17:41] <Daemon404> ^ basically this
[18:13] <rnissl> Hi, I've recently upgraded ffmpeg and it seams that AVCODEC_MAX_AUDIO_FRAME_SIZE is gone. How shall client programs be updated that formerly used that constant?
[18:16] <kierank> Daemon404: ^
[18:17] <nevcairiel> that constant shouldn't be needed at all anymore
[18:17] <Daemon404> kierank, are you referring how how i argued that it wasnt documented anywhere?
[18:17] <Daemon404> thats gotta be it.
[18:17] <kierank> yup
[18:18] <Daemon404> rnissl, what nevcairiel said
[18:18] <rnissl> Hi Daemon404, nevcairiel -- what buffer size should a client use then?
[18:19] <Daemon404> youre gonna need a bit of context
[18:19] <nevcairiel> what for do you need a fixed buffer size?
[18:19] <rnissl> I'm trying to compile xinelib with latest ffmpeg
[18:20] <wm4> rnissl: that's going to need some API-changes probably...
[18:20] <Daemon404> wow xine
[18:20] Action: Daemon404 hasnt heard that name in ages
[18:20] <rnissl> and that code used that constant for a buffer
[18:21] <rnissl> it allocated
[18:21] <Daemon404> buffer for what
[18:21] <rnissl> bytes_consumed =
[18:21] <rnissl>           ff_audio_decode(this,
[18:21] <rnissl>                           (int16_t *)this->decode_buffer, &decode_buffer_size,
[18:21] <rnissl>                           &this->buf[offset], this->size);
[18:21] <wm4> ff_ 
[18:21] <wm4> what
[18:21] <Daemon404> ... oesn xine bastardize ffmpeg internals?
[18:21] <Daemon404> does*
[18:22] <nevcairiel> nah it probably just names its function with ffmpegs namespace
[18:22] <nevcairiel> anyhow, it probably still uses decode_audio3, which needed a user-allocated buffer
[18:22] <Daemon404> yeah
[18:22] <Daemon404> almost everyone used AVCODEC_MAX_AUDIO_FRAME_SIZE for audio3
[18:22] <rnissl> ff_ ... calls av_parser_parse2() with that buffer
[18:23] <Daemon404> the proper solution is to update your api used to a non-deprecated api
[18:23] <Daemon404> the horribly and hacky solution is s/AVCODEC_MAX_AUDIO_FRAME_SIZE/192000/
[18:24] <rnissl> I see in the code a call to avcodec_decode_audio3() which doesn't need that buffer
[18:26] <rnissl> oh, it only passes it in via AVPacket
[18:26] <rnissl> ok -- for now I'll just replace that constant with 192000
[18:27] Action: Daemon404 really shouldnt have suggested that
[18:29] <rnissl> I'm sure, the xine hackers will adopt the new api soon ;-)
[18:33] <rnissl> thanks for your help
[19:41] <nevcairiel> guy finds a trac entry about x264 crashing, trac entry says "ask on x264-devel" ... guy sends mail to ffmpeg-devel referecing the trac entry....
[19:41] Action: nevcairiel shakes his head
[19:41] <Daemon404> nevcairiel, x264-devel gets ffmpeg email too
[19:42] <Daemon404> its great
[19:42] <nevcairiel> but he did read the trac entry, which told him where to go..
[19:43] <michaelni> maybe tell him to ask on ffmpeg-devel
[20:14] <ubitux> llogan: error handling in the script should be better :p
[20:42] <llogan> ubitux: excellent
[20:47] <ubitux> with the encode option, the script should actually be usable out of the box now
[21:33] <cone-880> ffmpeg.git 03Michael Niedermayer 07master:644092c8e889: h264: dont report rows as finished after a missing slice
[23:02] <Daemon404> i should turn tha tvm on
[23:54] <cone-880> ffmpeg.git 03Janne Grunau 07master:70db0c91563f: fate: use little endian yuv444p10 in h264-reinit tests
[23:54] <cone-880> ffmpeg.git 03Michael Niedermayer 07master:62f56fd7eae0: buffersink/uninit: use av_frame_free() not unref
[00:00] --- Sun Mar 24 2013