[Ffmpeg-devel-irc] ffmpeg-devel.log.20121207
burek
burek021 at gmail.com
Sat Dec 8 02:05:02 CET 2012
[00:10] <saste> michaelni, ubitux: maybe i'll work tomorrow on the volume thing, but feel free to beat me
[00:10] <ubitux> ok
[00:11] <ubitux> thanks for the ports to filter_frame :)
[00:14] <ubitux> ok i found the problem with the mmx in gradfun
[00:19] <ubitux> two instructions seem switched
[00:21] <ubitux> it works \o/
[00:25] <ubitux> ok now removing the rounding for ssse3 and we're good.
[00:26] <ubitux> yay
[00:26] <ubitux> C, MMX and SSSE3 working :)
[00:27] <cone-556> ffmpeg.git 03Carl Eugen Hoyos 0724b20087bd1f: Fix compilation with yasm 0.6.2.
[00:28] <ubitux> so i found 3 bugs
[00:28] <ubitux> one in C, one in MMX and one in SSSE3
[00:28] <ubitux> all 3 differents
[00:30] <iive> good work ubitux . are any of these bugs presented in the mplayer filter?
[00:30] <ubitux> likely yes
[00:31] <ubitux> actually, there was 2 bugs in MMX :)
[00:39] <durandal_1707> fuck you libav
[00:39] <durandal_1707> michaelni: i ask to not merge libav tak code
[00:42] <ubitux> haha
[00:42] <ubitux> what did they do?
[00:43] <durandal_1707> renamed file
[00:45] <ubitux> :D
[00:55] <durandal_1707> and it added .init_static_data which is called when registering all codecs
[00:55] <durandal_1707> which is stupid, it should be called only once and only when really needed
[00:56] <durandal_1707> which current code already did
[00:58] <ubitux> pengvado: comments welcome on the gradfun patchset
[01:02] <durandal_1707> ubitux: actually no rename happened (yet)
[01:12] <cone-556> ffmpeg.git 03Paul B Mahol 074e4a95b18e8d: takdec: remove get_code() and use get_sbits() directly
[01:17] <cone-556> ffmpeg.git 03Paul B Mahol 076a7fed193cbf: add missing dependency for tak demuxer
[01:24] <ubitux> iive: looking quickly, the code seems the same
[01:24] <ubitux> it was unlikely to be some port mistakes though
[02:22] <cone-556> ffmpeg.git 03Paul B Mahol 07f8d68822c0f9: takdec: use samplefmt.h from libavutil
[02:25] <cone-556> ffmpeg.git 03Michael Niedermayer 07b84d1bf193d2: diracdec: fix emulated_edge condition, fix out of array reads
[02:25] <cone-556> ffmpeg.git 03Michael Niedermayer 072f6ec9fdd780: diracdec: Test mctmp and mcscratch for malloc failure.
[02:25] <cone-556> ffmpeg.git 03Michael Niedermayer 07f5d6b0c9c2bd: diracdec: fix typo in mctmp allocation
[04:13] Action: Daemon404 wonders wtf is going on
[04:13] <Daemon404> im literally valling avformat_seek_file with teh same values as ffmpeg_opt.c is
[04:14] <Daemon404> but it returns a different frame than my code
[04:14] <Compn> obviously theres some other code that ffmpeg uses but you dont use
[04:14] <Daemon404> yeah g/l finding that
[04:14] <Daemon404> it's a spagbog
[04:15] <Compn> either in demuxer or a/v sync
[04:15] <Compn> are you using lavf demuxer or custom ?
[04:15] <Daemon404> lavf
[04:15] <Daemon404> and there is no audio
[04:15] <Compn> are you using libav ? :P
[04:16] <Compn> ehe
[04:16] <Daemon404> no.
[07:52] <nevcairiel> wm4: re framesize changes in hw decoding, the h264 decoder just handles that itself, and you need to be aware of it in the get_buffer call, what i do is simply recreate all gpu buffers in the new size when a change happens, calling avcodec_flush_buffers in the process to free all remaining resources (if any)
[10:09] <j-b> https://trac.videolan.org/vlc/ticket/7860
[11:48] <wm4> what is reget_buffer? I don't understand this
[11:48] <nevcairiel> it requests the old buffer again for re-use
[11:49] <nevcairiel> its sometimes used for cheap inter-frames to get the previous frame to apply the differences
[11:49] <nevcairiel> no serious codec really uses it
[11:50] <wm4> I suppose the default reget_buffer will always work even if the user overrides get_buffer and release_buffer? (as long as the codec reports DR1 support)
[12:12] <nevcairiel> yes, it will just copy the buffer then
[12:12] <nevcairiel> as long as you set the buffer type to _USER
[12:12] <nevcairiel> or how it was called
[12:12] <nevcairiel> anything but the internal type, anyway
[12:15] <wm4> also, why are cmdutils.c's get_buffer implementation and the avcodec internal one different? that seems like some really bad code duplication..
[12:15] <wm4> fortunately, The Evil Plan will make this unnecessary
[14:01] <cone-642> ffmpeg.git 03Michael Niedermayer 07ea6da80cb41a: diracdec: check dimensions against chroma format.
[14:08] <mateo`> i'm going to port vf_setfield to filter_frame api
[14:09] <cone-642> ffmpeg.git 03Paul B Mahol 078ca8b43d7108: lavf/pcm: check size, do not produce invalid packets
[14:13] <ubitux> mateo`: ah we missed that one, thx
[14:29] <ubitux> seems like the ivtc filter won't be much effort to port actually
[14:29] <ubitux> i guess i'll do it
[14:29] <ubitux> and we already have a decimate filter so&
[14:33] <ubitux> but i need to fix something in vobsub first
[15:27] <cone-642> ffmpeg.git 03Justin Ruggles 07ecc8b0219446: x86: float_dsp: fix compilation of ff_vector_dmul_scalar_avx() on x86-32
[15:27] <cone-642> ffmpeg.git 03Justin Ruggles 07b64ba37c4c0d: Changelog: add an entry for deprecating the avconv -vol option
[15:27] <cone-642> ffmpeg.git 03Diego Biurrun 0733086f92652b: fate: image: Add dependencies
[15:27] <cone-642> ffmpeg.git 03Christophe Gisquet 079a16359c3888: AAC SBR: use AVFloatDSPContext's vector_fmul
[15:27] <cone-642> ffmpeg.git 03Christophe Gisquet 072aef3d66c9cd: SBR DSP x86: implement SSE sbr_hf_gen
[15:27] <cone-642> ffmpeg.git 03Diego Biurrun 07c25fc5c2bb6a: fate: dpcm: Add dependencies
[15:27] <cone-642> ffmpeg.git 03Michael Niedermayer 07af164d7d9f12: Merge commit 'c25fc5c2bb6ae8c93541c9427df3e47206d95152'
[15:44] <ubitux> these align "cosmetics" are more and more ridiculous&
[15:44] <ubitux> - s->ic = s1;
[15:44] <ubitux> + s->ic = s1;
[15:44] <ubitux> plz
[15:50] <durandal_1707> ubitux: ?
[15:50] <ubitux> durandal_1707: one of the last K&R patch on l
[15:50] <durandal_1707> then do not merge
[15:51] <ubitux> well, it's not broken or anything
[15:51] <ubitux> some style changes are just stupid
[15:51] <ubitux> breaking some lines too
[15:52] <ubitux> i don't understand why Diego doesn't focus on documentation instead, if he doesn't want to write code
[15:52] <ubitux> but well, whatever.
[15:53] <durandal_1707> he had lobotomy
[15:58] <cone-642> ffmpeg.git 03Janne Grunau 07480be07a9637: flac: change minimum and default of lpc_passes option to 1
[15:58] <cone-642> ffmpeg.git 03Janne Grunau 0780b6b31417c6: mov: compute avg_frame_rate only if duration is known
[15:58] <cone-642> ffmpeg.git 03Janne Grunau 078cc2fa1e5db0: mov: validate number of DataReferenceBox entries against box size
[15:58] <cone-642> ffmpeg.git 03Janne Grunau 07d7d6efe42b0d: h264: check sps.log2_max_frame_num for validity
[15:58] <cone-642> ffmpeg.git 03Michael Niedermayer 077c425e4f2d67: Merge commit 'd7d6efe42b0d2057e67999b96b9a391f533d2333'
[16:05] <cone-642> ffmpeg.git 03Paul B Mahol 071c779854b529: lavc/takdec: simplify code
[16:16] <cone-642> ffmpeg.git 03Martin Storsjö 074ed0c35c40b7: avcodec: Fix a typo in an option description
[16:17] <ubitux> (holding such commit is fucking braindead)
[16:20] <durandal_1707> ubitux: why it is still in hold?
[16:21] <nevcairiel> git log clutter, apparently
[16:21] <ubitux> Diego wants to find more of them before sending a patch
[16:22] <durandal_1707> bliss
[16:22] <cone-642> ffmpeg.git 03Paul B Mahol 076777aa638791: lavc/takdec: s/get_b/get_bits_esc4
[16:22] <ubitux> durandal_1707: please stop cluttering history with commits plz
[16:23] <ubitux> fix 10 bugs at one or don't fix them
[16:23] <ubitux> once*
[16:33] <durandal_1707> you want me to pull all changes to various files in single commit and send it for review after diff reach 1000 lines once in month?
[16:34] <ubitux> sounds nice
[16:35] <ubitux> if you do that, at least the git diff stats between commit will be consistent
[16:35] <ubitux> and everyone knows how consistency is important
[16:36] <ubitux> consistency overrule common sense
[16:37] <durandal_1707> so no more cosmetics commits that remove single letter?
[16:38] <ubitux> yes please, wait for more
[16:39] <Compn> durandal_1707 : what codecs are you working on now? :)
[16:40] <durandal_1707> Compn: all work is suspended as of now, patch that adds new demuxers/decoders should be more that 1000 loc
[16:40] <ubitux> :D
[16:40] <ubitux> no durandal_1707, it should be 1000 loc
[16:40] <nevcairiel> so write two
[16:41] <ubitux> if you overflow, do some cosmetics to make it match 1k
[16:41] <ubitux> if not, split
[16:41] <ubitux> and wait for 2k
[16:41] <Compn> durandal_1707 : lol :D
[16:42] <ubitux> remember, code that goes in ffmpeg is either broken or trivial, so no point in having less than 1k loc
[16:44] <durandal_1707> please define trivial and broken
[16:45] <ubitux> trivial: they are not mainstream codecs, broken: there are typo in the commit messages!
[16:47] <Compn> durandal_1707 : i think ubitux is making fun of libav policies
[16:47] <Compn> dont take them personal :)
[16:48] <ubitux> i would never do that Compn
[16:57] <durandal_1707> ubitux: do those rules apply to libswscale too?
[17:00] <ubitux> durandal_1707: no idea, ask Diego
[17:01] <ubitux> or another l guy
[17:01] <ubitux> they will say it should be dropped in a single commit i guess
[17:01] <ubitux> even if it's more than 1k loc
[17:01] <ubitux> it's not consistent, but that's michael fault this time so we can live with that
[17:02] <Compn> so after diego racked up 8K commits , now he changes ?
[17:02] <Compn> (going by ohloh count)
[17:04] <cone-642> ffmpeg.git 03Janne Grunau 07a394959bbee9: h264: add a pointer for weighted prediction temporary buffer
[17:04] <cone-642> ffmpeg.git 03Michael Niedermayer 07857d7194ca6d: Merge remote-tracking branch 'qatar/master'
[17:08] Action: durandal_1707 going in little adventure
[17:09] <michaelni> j-b, I cannot reproduce a issue with ffmpeg and poc.swf from vlcticket 7860
[17:09] <michaelni> tried valgrind and asan
[17:17] <teratorn> hi is there a runtime method for getting the overall ffmpeg version/git-commit-hash?
[17:18] <teratorn> I am assuming not since each libav* is versioned separately
[17:20] <ubitux> you can access "FFMPEG_VERSION"
[17:20] <ubitux> which should contain something like "N-47560-gbc45b06"
[17:20] <teratorn> where do I get FFMPEG_VERSION ?
[17:21] <ubitux> version.h
[17:21] <teratorn> yeah....
[17:21] <ubitux> generated with version.sh
[17:21] <teratorn> so not a standard include file
[17:21] <teratorn> :/
[17:21] <ubitux> ah you're interested for an external app?
[17:21] <teratorn> and likely as not to be a big fat lie in the face of dynamic linking
[17:21] <ubitux> you have library versions then
[17:21] <teratorn> yeah :/
[17:21] <ubitux> what's the problem?
[17:21] <teratorn> I guess you can't do better really
[17:22] <teratorn> I just want to know what version I'm running
[17:22] <wm4> who would install mismatches library versions?
[17:22] <ubitux> did we forget to bump after an api/abi break?
[17:22] <teratorn> no, nothing
[17:22] <teratorn> for my own debugging purposes
[17:22] <teratorn> wm4: someone that wants to break my app, I guess! :)
[17:23] <teratorn> it probably wouldn't hurt to include a thing in the libraries themselves, that references the source tree version somehow
[17:24] <ubitux> saste: it seems sendcmd, idet, overlay, setfield, swapuv and maybe sink_buffer need some updates (startframe callback); you are on overlay i believe, mateo` is doing setfield, idet is pending, should i take one of the remaining?
[17:24] <teratorn> e.g., for libvpx you see, [libvpx @ 0x82fb20] v1.1.0-332-g9961ad4
[17:25] <saste> swapuv is mine
[17:25] <teratorn> LIBAV<WHICH>_FFMPEG_VERSION
[17:25] <saste> same for sendcmd and overlay
[17:25] <teratorn> to avoid conflicting namespace
[17:25] <teratorn> *shrug*
[17:25] <saste> teratorn, there is an open ticket for that feature (global version number)
[17:25] <saste> please upvote it
[17:25] <teratorn> saste: ok boss :)
[17:26] <ubitux> we can just add a function to return FFMPEG_VERSION :p
[17:26] <saste> ubitux, it's not that simple because the version is created by configure
[17:26] <teratorn> being able to bake it in at compile time isn't necessarily bad
[17:27] <wm4> I have to deal with mpg streams that randomly change; is there a way to completely reset an AVFormatContext?
[17:32] <teratorn> saste: I can't seem to find the ticket #, any clue?
[17:44] <saste> teratorn, can't find it as well, either I dreamt the ticket or it has been "closed" for whatever reason
[17:44] <saste> feel free to create a new one
[17:45] <teratorn> saste: ok, thanks
[18:00] <durandal11707> anyone have aol art dll?
[18:12] <teratorn> any ffmpeg devels avail for consulting? got a prob adding vorbis stream to webm and serving it over http
[18:13] <teratorn> my company has a budget for this kind of help :)
[18:13] <teratorn> msg me if interested and if you are knowlegable about encoders/muxers, thanks :)
[19:01] <cone-642> ffmpeg.git 03Paul B Mahol 07fe63d4130235: brstm: do not return partial packets
[19:10] Action: ubitux wonders what the ppl who designed dvd subtitles were thinking
[19:11] <cone-642> ffmpeg.git 03Stefano Sabatini 071f467220cfd1: lavfi/alphaextract: drop cur_linesize = out_linesize branch in draw_slice()
[19:20] <saste> mateo`, can you push patches?
[19:22] <wm4> ubitux: what's the problem?
[19:23] <ubitux> wm4: the split is completely insane
[19:23] <wm4> split?
[19:24] <ubitux> yes packets are split into small chunks
[19:24] <wm4> oh
[19:24] <ubitux> so you have to read the first chunk to get the total size
[19:24] <ubitux> but sometimes that size is wrong
[19:25] <ubitux> saste: i think he hasn't write perm
[19:46] <cone-642> ffmpeg.git 03Stefano Sabatini 07c3ad91a3d77c: lavfi/alphaextract: switch to filter_frame() API
[19:46] <cone-642> ffmpeg.git 03Stefano Sabatini 07130c6497d2e5: lavfi/alphaextract: fix assignment of invalid size value to memcpy in case linesize < 0
[19:46] <cone-642> ffmpeg.git 03Stefano Sabatini 070bc0d31b7b5c: lavfi/alphaextract: access outlink properties rather than out_buf->video
[19:47] <cone-642> ffmpeg.git 03Stefano Sabatini 07fe508f807abd: lavfi/alphaextract: consistently prefer "cur" over "in" in filter_frame()
[19:49] <ubitux> erm it seems compare filter in l is delayed again
[19:50] <ubitux> we should have write it ourselves
[19:51] <saste> ubitux: do you want to work on my cmp filter?
[19:51] <ubitux> i'm not particularly interested (except as a user), but mateo` might be
[19:52] <ubitux> saste: i'll likely work on an ivtc filter next
[19:52] <ubitux> looks like the StyleSubtitles will be delayed again
[19:52] <ubitux> :))
[19:55] <Daemon404> oh boy...
[19:56] <Daemon404> my code crashes in swscale when resizing when resizing to 100x1000, but not 1000x1000 or 1000x100
[19:56] <Daemon404> s/when resizing //
[19:57] <ubitux> then stop resizing to 100x1000
[19:57] <ubitux> sounds like a bad size anyway
[19:57] <Daemon404> this is generic resizing
[19:57] <Daemon404> and that's a shit response.
[19:57] <ubitux> that was not meant to be taken seriously
[19:57] <Daemon404> hard to hell anymore
[19:58] <Daemon404> seen it too much on the ML over teh years
[19:58] <Daemon404> ;)
[19:59] <ubitux> funny how ffplay behaves when you do that
[19:59] <Daemon404> ?
[20:00] <Daemon404> i havent checked
[20:00] <Daemon404> it fails all teh way up to 940x1000 btw
[20:00] Action: Daemon404 runs ffplay
[20:00] <ubitux> ffplay -f lavfi -i testsrc -vf scale=100:1000 this is weird
[20:00] <ubitux> the width seems not honored
[20:01] <ubitux> while with tests/lena.pnm it is
[20:01] <Daemon404> yeah
[20:01] <Daemon404> there is some arcane magic...
[20:01] <Daemon404> -_-
[20:03] <saste> uhm some part of the code is acting smart and changing sar in order to honor the original DAR
[20:03] <saste> maybe it is the scale filter itself
[20:03] <saste> and depending on the size ffplay crashes bad
[20:04] <saste> dunno if it is c***y SDL or our funny code
[20:04] <Daemon404> i see
[20:04] <Daemon404> im having a hard time figuring out why my sws_scale call is crashing myslef
[20:04] <Daemon404> ffmpeg.c seems to resize fine
[20:07] <Daemon404> im converting to RGB25 from YUV420P and scaling at the same time, if it matters
[20:09] <Daemon404> http://pastebin.com/ePtXryvn <-- relevant bit
[20:13] <Daemon404> http://pastebin.com/raw.php?i=mdPJ7Sik <-- and a br
[20:13] <Daemon404> bt*
[20:19] <saste> well a crash is a bug
[20:19] <Daemon404> for all i know i ste it up wrong or didnt allocate something properly
[20:19] <saste> -> ticket or ask someone which knows about libswscale
[20:19] <saste> *who
[20:20] <Daemon404> onyl 2 people knwo about swscale.
[20:20] <Daemon404> period.
[20:20] <Daemon404> only 1 is in here
[20:21] <Daemon404> srcStride2 = {1312, 656, 656, 0}
[20:21] <Daemon404> dstStride2 = {3840, 0, 0, 0}
[20:21] <Daemon404> well thats certainly interesting
[20:21] <Daemon404> (thats for 940x1000
[20:22] <saste> gotta go
[20:23] <Daemon404> DOH
[20:23] <Daemon404> avpicture_fill((AVPicture *) ctx->rgb, ctx->rgb_buf,
[20:23] <Daemon404> PIX_FMT_RGB24, ctx->yuv->width, ctx->yuv->height);
[20:23] <Daemon404> spot the issue
[20:23] <wm4> one person per fork?
[20:24] <Daemon404> this is an app using the the api
[20:24] <Compn> maybe he means michael and the devil
[20:24] <Daemon404> these thinsg exist you know
[20:24] <Compn> :P
[20:24] <Daemon404> michael and ronald
[20:25] <ubitux> so you found the arcane magic in your code?
[20:25] <Daemon404> it turned out not to be that
[20:26] Action: ubitux gives a nice magician hat to Daemon404 in thanks for the tin foil one
[20:28] <Daemon404> ubitux, turns out that rather than return errors on obviously invalid input, it just crashes
[20:28] <Daemon404> :/
[20:28] <wm4> that'll teach the API user
[20:29] <Daemon404> libav* api's response to most things is crahsing :P
[20:29] <ubitux> what is obvious?
[20:29] <ubitux> how could it guess if you're passing the size of your input instead of the size of the output?
[20:30] <Daemon404> ubitux, i was actually passing 0
[20:30] <Daemon404> cause i had some stuff out of order
[21:09] <durandal11707> ubitux: are l guys aware of 24bit wmalossless sample on our tracker?
[21:10] <nevcairiel> who knows, but they have samples themself
[21:10] <durandal11707> 24bit ones?
[21:10] <nevcairiel> yes
[21:11] <nevcairiel> i saw talk about implementing it, but it never went anywhere yet
[21:19] <cone-642> ffmpeg.git 03Clément BSsch 07710c4baf528c: lavf: VobSub demuxer.
[21:20] <Compn> whoa
[21:21] <Compn> but can you display them yet ? :P
[21:21] <ubitux> ffplay seems to have some trouble with them
[21:22] <ubitux> when i use it to mux the sub into mkv, mplayer & friends are able to display them
[21:25] <Daemon404> huh... jpeg encoder wont encode without a framerate?wut
[21:25] <Daemon404> i just wanna encode single jpeg
[21:27] <wm4> AFAIK you need to set time_base?
[21:29] <Daemon404> you do
[21:29] <Daemon404> which is stupid for a single jpeg image
[21:29] Action: Daemon404 set it to 3/1337
[21:30] <Daemon404> now to figure out how to set a 'quality' via the api
[21:30] <Daemon404> or even enable q mode
[21:32] <wm4> Daemon404: tell me how to do it if you figure out
[21:33] <Daemon404> reading mpegvideo*c
[21:33] <Daemon404> :V
[21:34] <wm4> lol.
[21:34] <Compn> why not just read the example or other project utilizing ffmpeg api ?
[21:34] <Daemon404> 1) the example is worthless for this. dont speak of what you havent looked at.
[21:34] Action: Compn sees mencoder using api ...
[21:34] <Compn> bah
[21:34] <Daemon404> mencoder doesnt use teh api
[21:34] <Daemon404> it rips out internal shoit
[21:34] <Daemon404> it cant survive o nthe pai
[21:35] <Daemon404> also it's a giant mess of crap
[21:35] <Daemon404> and given wm4 works on an mplayer fork and doesnt know
[21:35] <nevcairiel> its like mplayer, just worse
[21:35] <Daemon404> it's unlikely ill find it there.
[21:36] <Compn> wm4 works on a fork that removed mencoder
[21:36] <Compn> but ok bro, talk about stuff you havent looked at
[21:36] <Daemon404> ive tried to read mencoder before
[21:36] <Daemon404> Bad IDea
[21:36] <wm4> mencoder was removed from mplayer2 a long time ago, I've never seen much of mencoder code (and I'm thankful for it)
[21:37] <Daemon404> gmm
[21:37] <Daemon404> avctx->flags |= CODEC_FLAG_QSCALE makes the encoder crash
[21:37] <Daemon404> with a div by 0
[21:37] <Daemon404> nice.
[21:38] <Compn> lavc_venc_context->flags |= CODEC_FLAG_QSCALE;
[21:38] <Compn> lavc_venc_context->global_quality=
[21:38] <Compn> vf->priv->pic->quality = (int)(FF_QP2LAMBDA * lavc_param_vqscale + 0.5);
[21:38] <Compn> }
[21:38] <Daemon404> oh right
[21:38] <Daemon404> that retarded FF_QP2LAMBDA crap
[21:38] <Daemon404> inb4 FF_QP2LAMBDA is not public
[21:39] <nevcairiel> its called FF
[21:39] <nevcairiel> it shouldnt be :P
[21:39] <Daemon404> exactly
[21:39] <Compn> FF can be both, apparently...
[21:39] <Daemon404> no, it isnt supposed to be.
[21:39] <Compn> because sometimes it needed a header to avoid conflicts with sys headers
[21:39] <Compn> a prefix*
[21:40] <Daemon404> FF_ is internal Compn
[21:40] <Daemon404> end of story
[21:41] <Daemon404> i dont think i need it...
[21:41] <nevcairiel> the rules seem simple, FF* is private, AV* is public, and there are some special cases of sharing between libs for avpriv*, but only on functions, not defines
[21:41] <nevcairiel> obviously there are old things which dont obey those rules
[21:44] <Daemon404> 0x00007ffff6fc9328 in ff_MPV_encode_picture (avctx=0x7ffff00b0160, pkt=0x7ffff00009e0, pic_arg=0x7ffff000aa20, got_packet=0x7ffff49fdda4) at /home/vimeo/b/ffmpeg/libavcodec/mpegvideo_enc.c:1527
[21:44] <Daemon404> 1527 uint8_t *start = pkt->data + (size_t)(((int64_t) pkt->size) * start_y / h);
[21:44] <Daemon404> interesting place to crash...
[21:48] <ubitux> there is a /b/ on vimeo? nice
[21:49] <ubitux> hi Jake
[21:51] <Daemon404> heh
[21:52] <Daemon404> wait... inb4 edge emu
[21:52] <Daemon404> thought it shouldnt be since im usign default get/release
[21:56] <cone-642> ffmpeg.git 03Michael Niedermayer 07320ae9fb784f: sws_scale: check input against NULL
[22:01] <Daemon404> gah
[22:02] <Daemon404> cannot figure it out
[22:03] <Compn> "One of the input parameters to sws_scale() is NULL, please check the calling code\n"
[22:03] <Compn> lol :D
[22:03] <ubitux> :)
[22:04] <ubitux> "Daemon404 please check your code\n"
[22:04] <michaelni> btw, about FF vs AV, that private/public distinction is more recent than some of these identifers
[22:04] <Daemon404> i know
[22:05] <Daemon404> michaelni, is there anythign special i need to set up after i flags |= CODEC_FLAG_QSCALE
[22:05] <Daemon404> and opening/calling the encoder
[22:05] <michaelni> the qscale / quality
[22:05] <Daemon404> i set the quality
[22:05] <Daemon404> avctx->global_quality and frame->quality
[22:05] <Compn> post yer code to pastebin
[22:05] <Daemon404> (latter seems unneeded)
[22:05] <Daemon404> Compn, companies tend to frown on that
[22:06] <Compn> developers frown on guessing whats wrong with your code too
[22:06] <Compn> no offense
[22:06] <Compn> just going from what i've seen in the past...
[22:06] <Daemon404> Compn, good thign youre not a developer here.
[22:06] <Compn> yes, no one should trust me with git commit access :)
[22:07] <Daemon404> michaelni, i dont see a place to set 'qscale'
[22:10] <michaelni> i meant avctx->global_quality and frame->quality, qscale gets set by mpegvideo stuff
[22:10] <nevcairiel> ffmpeg just sets global_quality to FF_QP2LAMBDA * qscale
[22:16] <Daemon404> michaelni, damn.. i have that set
[22:17] <Daemon404> crash only happens with mjpeg+qscale mode.. fun times
[22:18] <Daemon404> s->mb_height is 0 for some reason
[22:20] <michaelni> height is not 0 ?
[22:21] <Daemon404> W: 400 H: 200
[22:22] <Daemon404> printed as the last thing before i call encode_video
[22:22] <Daemon404> thats avctx->width and avctx->height
[22:22] <Daemon404> (which match frame->width and frame->height)
[22:24] <wm4> there's one thing I don't get about DR: what about the case where it would be practical to reuse a previous reference frame? does libavcodec always copy in that case?
[22:25] <wm4> maybe I'm missing something
[22:25] <michaelni> theres reget_buffer()
[22:25] <nevcairiel> isnt that were reget_buffer comes in?
[22:25] <nevcairiel> the default doesnt copy
[22:26] <michaelni> Daemon404, do you check the return codes of functions ? (a failing avcodec_open() might cause such a problem you describe)
[22:26] <Daemon404> i do
[22:26] <Daemon404> every single one
[22:26] <Daemon404> michaelni, i cant actually find where s->mb_height is set for mjpeg
[22:26] <Daemon404> i see mpeg2, h264.... but no mjpeg
[22:26] <wm4> nevcairiel: I thought reget_buffer was rarely used
[22:27] <nevcairiel> well i don't know what you had in mind =P
[22:27] <nevcairiel> reference frames are of course also stored to be used as reference
[22:27] <nevcairiel> but they are usually not output as-is again without copying
[22:27] <nevcairiel> if thats ever needed
[22:27] <nevcairiel> unless the codec uses reget buffer
[22:28] <Daemon404> you never need to override reget_buffer
[22:28] <Daemon404> just fyi
[22:28] <Daemon404> well, you shouldnt need to.
[22:28] <nevcairiel> well if you dont want it to copy your custom buffer, you might want to
[22:29] <Daemon404> heh
[22:29] <wm4> cmdutils.c (well, its users) don't set reget_buffer either
[22:29] <michaelni> Daemon404, mb_heuight should be set in ff_MPV_common_init
[22:30] <michaelni> also do you use multithreading ?
[22:30] <michaelni> if yes try without
[22:30] <Daemon404> i use whatever teh default is in teh api
[22:30] <Daemon404> which i thought was 1
[22:32] <wm4> h264 doesn't seem to use reget_buffer, so I guess it's indeed best not to care
[22:32] <nevcairiel> yeah like i said, only fringe codecs use it really
[22:33] <nevcairiel> any smart codecs with possibly even multiple references store the refs internally themself
[22:33] Action: Daemon404 wrote a fringe codec that used it
[22:33] <wm4> still, I find it strange that a decoder like h264 would actually copy reference frames which could just be reused?
[22:34] <nevcairiel> in what case would it just take an old reference and output it as-is? how common is that really?
[22:35] <wm4> hm I see, so that behavior wouldn't be that useful anyway
[22:35] <Daemon404> (forcing 1 threads = same issue)
[22:35] <wm4> nevcairiel, Daemon404: thanks, sorry for asking stupid questions all the time
[22:37] Action: Daemon404 asks far more stupid questions than wm4
[22:37] <nevcairiel> Daemon404: the only way i see those are not set is when avcodec_open fails
[22:37] <nevcairiel> mb_height that is
[22:37] <Daemon404> ret = avcodec_open2(ctx->encctx, out_codec, NULL);
[22:37] <Daemon404> if (ret < 0)
[22:37] <Daemon404> goto fail;
[22:37] <Daemon404> ^
[22:40] <Daemon404> oh well
[22:40] Action: Daemon404 puts a shitload of printfs in ff_MPV_common_init
[22:41] <wm4> debugging in 2012
[22:41] <Daemon404> wm4, debugging on linux
[22:41] <Daemon404> you mena
[22:41] <Daemon404> :P
[22:41] <Daemon404> it's less painful than using gdb
[22:41] <Daemon404> to bp and step\
[22:42] <wm4> sadly
[22:42] <nevcairiel> sadly this wouldn't be much more fun on windows because of the f'ing requirement of optimizations during build
[22:42] <nevcairiel> its good enough for spoting things on break points, but optimized-out variables can make peeking into values a pain
[22:43] <Daemon404> nevcairiel, on windows you could use a pragma
[22:43] <Daemon404> since you knwo exactly teh chunk you wanna see
[22:43] <nevcairiel> oh yeah, i guess could disable the optim there
[22:43] <Daemon404> also, did you see ms acknowledged teh bug in their compiler
[22:43] <Daemon404> for pcm_u8?
[22:43] <nevcairiel> i always forget about that
[22:43] <nevcairiel> what bug?
[22:44] <nevcairiel> i reported a crash in the 2012 compiler and it never really got responded to
[22:44] <Daemon404> http://connect.microsoft.com/VisualStudio/feedback/details/773348
[22:44] <Daemon404> michaelni, so in the init func, it's getting s->height == 0
[22:44] <Daemon404> where s is mpegenccontext
[22:45] <Daemon404> (which i am scared of)
[22:45] <nevcairiel> this is set to avctx->height one function before in the chain
[22:45] <nevcairiel> s->height = avctx->height;
[22:45] <nevcairiel> in ff_MPV_encode_init
[22:45] <Daemon404> i dumped avctx->height right before encode_video
[22:45] <Daemon404> it's seriously unpossible
[22:46] <nevcairiel> look at ff_MPV_encode_init, its directly set from the avctx, something must be going funny
[22:47] <Daemon404> time to put printfs inside encode_init
[22:47] <Daemon404> wait a second...
[22:48] <Daemon404> AHHHHHHHHHHHH
[22:48] <Daemon404> brb suicide
[22:48] <nevcairiel> lol
[22:49] <nevcairiel> see, showing us code may have solved this an hour ago!
[22:49] <Daemon404> nevcairiel, not my call man
[22:49] <wm4> what was it?
[22:49] <Daemon404> i was setting avctx->w/h before encoe_video, but after avcodec_open2
[22:50] <Daemon404> like a derp
[22:50] <nevcairiel> hah
[22:50] <wm4> fun
[22:50] <Daemon404> and crashes because input validation is for losers
[22:50] <nevcairiel> and i thought you might've learned checking the order of things after your swscale adventure :D
[22:50] <Daemon404> nevcairiel, i wasted far too much time stuck in mpeg*c-land
[22:52] <wm4> I'd just blame the libav* API design...
[22:52] <Daemon404> hey the other day
[22:52] <Daemon404> the api informed me i needed to call teh network init func
[22:52] <Daemon404> cause my functionality was deprecated
[22:53] <Daemon404> (printed to stderr)
[22:53] <Daemon404> i was impressed!
[22:53] <nevcairiel> i dont think you actually need to call it though
[22:53] <nevcairiel> its for future use or something
[22:53] <Daemon404> nevcairiel, yes but i did it anyway
[22:53] <Daemon404> to shut it up
[22:54] <Daemon404> now i just need to figure out what a sane qp is for a jpeg
[22:54] <Daemon404> (thumb)
[22:54] <wm4> that's why I'm still using libjpeg for screenshots...
[23:03] <cone-642> ffmpeg.git 03Michael Niedermayer 07419ade4b6193: lavc: check dimensions for video encoders
[23:03] <nevcairiel> lol
[23:05] <Daemon404> michaelni's a ninja
[23:39] <ubitux> durandal11707: it seems libav added some bugs to your decoder
[23:39] <ubitux> it makes mru very angry
[23:39] <ubitux> :D
[23:41] <ubitux> libav adding bugs during the review, that's pretty impressive
[23:42] <iive> do you want to get an edge on libav in automated bug discovery?
[23:46] <Daemon404> oh this is nice
[23:46] <Daemon404> get_bits_longlong and get_bits64
[23:46] <Daemon404> duplicated api yo
[23:52] <ubitux> well you know who to thank
[23:59] <kierank> Daemon404: i made tons of api mistakes
[23:59] <kierank> when i first started using it
[00:00] --- Sat Dec 8 2012
More information about the Ffmpeg-devel-irc
mailing list