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

[burek]

[00:00] <michaelni> aballier, is there any software that still uses AVCODEC_MAX_AUDIO_FRAME_SIZE or decode_audio3 ?
[00:01] <durandal11707> hmm, if decode_audio3 is not removed, it should still be working...
[00:01] <michaelni> BBB, ok, ill add add the others to MAINTAINERS and you can add yourself/send me a patch/pull req when you have decided
[00:02] <Daemon404> BBB:
[00:02] <Daemon404> [16:08] <@Daemon404> i will start working on vp9 tomorrow -- if you give me a task
[00:02] <Daemon404> [16:08] <@Daemon404> so i dont conflict with someone else
[00:02] <durandal11707> because of constant API changes, some users decide to stop using libav*
[00:02] <BBB> Daemon404: inter frame coding!!!!!
[00:02] <Daemon404> well ok
[00:02] <BBB> if you're up for that
[00:03] <BBB> I can help out once intra is done, but at least for now it's a big wide open
[00:03] <Daemon404> i have no idea what it entails in vp9
[00:03] <Daemon404> givn vp9 has no spec
[00:03] <BBB> it starts with bitstream parsing
[00:03] <Daemon404> so ill have to see
[00:03] <BBB> you just do the same as what libvpx does
[00:03] <BBB> it's like reverse engineering
[00:03] <BBB> except you have the source
[00:03] <Daemon404> heh
[00:03] <BBB> so it _is_ easier
[00:03] <Daemon404> so like every day i touch ffmpeg
[00:03] <BBB> right
[00:03] <BBB> except this source is not ffmpeg's ;)
[00:04] <Daemon404> it has roots in on2
[00:04] <Daemon404> who i.. dont have the most respect for
[00:04] <Daemon404> <_< >_>
[00:04] <wm4> durandal11707: IMO the problem is that the libav* API is too low level
[00:04] <Daemon404> wm4, what you dont like to loop over packets?
[00:05] <wm4> it's hilarious how most of the ffmpeg examples are subtly or completely buggy/inapproriate/useless
[00:05] <Daemon404> if i am using a local file i always use ffms2
[00:05] <Daemon404> since it providers a higher level api
[00:06] <Daemon404> getframe(n) is extremely convenient.
[00:07] <Plorkyeran> wanting to grab a frame by frame number in one step is totally an obscure use-case not worth supporting
[00:07] <Daemon404> of course.
[00:08] <Plorkyeran> if anything ffms2's API forces the user to do twice as much crap as should be needed for basic uses
[00:08] <wm4> how long has ffms2 actually managed to keep ABI/API compatibility?
[00:08] <Plorkyeran> although I guess some of that's just a result of no default params/overloading in C
[00:08] <Plorkyeran> years?
[00:08] <Daemon404> wm4, ... 7 years now?
[00:08] <Plorkyeran> I broke API compatiblity in uh
[00:08] <Plorkyeran> 2011
[00:08] <Daemon404> wasnt that related to postproc
[00:09] <Plorkyeran> nah, added a param to the audio open function to control how to handle container-level audio delay
[00:09] <Daemon404> right. so one break since inception more or less
[00:09] <Daemon404> (also wow.. ffms2 is almost a decade old now i think)
[00:10] <Plorkyeran> no
[00:10] <Plorkyeran> 2008 or so?
[00:10] <Daemon404> it was 06 i think the first time it showed up ?
[00:10] <Plorkyeran> maybe ffms1
[00:11] <aballier> michaelni: a lot
[00:11] <aballier> michaelni: k3b for ex.
[00:11] <Daemon404> also AVCODEC_MAX_AUDIO_FRAME_SIZE is not related to decode_auio3
[00:11] <Daemon404> it was cargo culted, but not ACTUALLY related
[00:11] <aballier> michaelni: or gst-ffmpeg/libav
[00:11] <Plorkyeran> it was moved to its own repo 2009-06-03
[00:11] <Plorkyeran> and that was still a beta version
[00:12] <Daemon404> a single api break in 4-5 years is still pretty decent
[00:13] <wm4> if you maintain a project depending on libav*, you have to play catch-up literally all the time
[00:13] <michaelni> aballier, if its used it should stay in ffmpeg
[00:13] <Daemon404> i know, i maintain several
[00:13] <Daemon404> mostly i gave up on supporting anything but HEAD
[00:14] <Plorkyeran> tbh it's not as bad as it used to be
[00:14] <aballier> michaelni: it should be deprecated but all the code i've seen does buffer[AVCODEC_MAX_AUDIO_FRAME_SIZE] then give buffer to decode_audio3
[00:14] <Daemon404> aballier, that is wrong
[00:14] <Daemon404> even for that api
[00:14] <Daemon404> AVCODEC_MAX_AUDIO_FRAME_SIZE is NOT related to what the buffer size should be
[00:14] <Daemon404> its a BS cargo culted define
[00:14] <aballier> those apps should migrate to decode_audio4 though
[00:14] <Plorkyeran> ffms2 did AVCODEC_MAX_AUDIO_FRAME_SIZE * 10 for no apparent reason
[00:15] <Plorkyeran> until it was switched to decode_audio4
[00:15] <aballier> Daemon404: what should be the buffer size then ?
[00:15] <Daemon404> there was never a real way to guarantee a buffer size is right
[00:15] <Daemon404> its one of the reasons the api sucked
[00:15] <aballier> i remember it was not sufficient for some codecs
[00:15] <aballier> but like *4 or *10 was
[00:15] <Daemon404> thats basically just a arbitrary number
[00:15] <Daemon404> that happens to work OK
[00:16] <aballier> yep
[00:16] <Daemon404> also mostly people dont want to because they will need to bother with either:
[00:16] <Plorkyeran> a single frame can expand to an arbitrarily large size once decoded
[00:16] <Daemon404> a) use libswresample or libavresample to deinterleave
[00:16] <Daemon404> b) write their own deinterleave function
[00:16] <Plorkyeran> so any fixed-size output buffer is going to fail eventually
[00:16] <Daemon404> and thats :effort: for man
[00:16] <Daemon404> y
[00:16] <Daemon404> er, i mean interlave, not deinterleave
[00:16] <Daemon404> also typos.
[00:17] <wm4> why doesn't libswscale and lib*resample not use AVFrames for input and output? is there a specific reason or is everyone just too lazy to implement that
[00:17] <wm4> s/not//
[00:17] <Daemon404> i thought lib*resampe do
[00:17] <aballier> wm4: i asked the same thing some weeks ago, started to bake up some patches but got lazy :/
[00:17] <wm4> Daemon404: nope
[00:17] <Daemon404> maybe to be 'generic' ?
[00:18] <aballier> Daemon404: so far what i've been doing is the lazy fix: #ifndef + #define 192000 * 4
[00:18] <wm4> too generic?
[00:18] <Daemon404> aballier, like i said, the api sucked
[00:18] <Daemon404> it was deprecated for a reason
[00:18] <beastd> BS, it is because of constant API/ABI changes in all libav* libs :D
[00:19] <Daemon404> [18:18] <+wm4> too generic? <-- this is all of the libav* api
[00:19] <Daemon404> why its too low level.
[00:19] <Plorkyeran> you do need the low-level API
[00:19] <Plorkyeran> there just also needs to be a higher-level API
[00:19] <Daemon404> yes
[00:20] <Daemon404> and that api is ALMOST ffms2
[00:20] <wm4> almost?
[00:20] <Daemon404> i still have to do libav* api stuff for streaming
[00:20] <Daemon404> ffms2 requires a local file to index
[00:20] <Daemon404> maybe ill look into libvlc
[00:20] <wm4> so it needs to create an index beforehand
[00:20] <Daemon404> in memory at least
[00:20] <Daemon404> how else would it see kacurately?
[00:20] <Daemon404> with libav*'s api? lolno
[00:21] <Plorkyeran> seeking a stream doesn't exactly work anyway
[00:21] <Daemon404> Plorkyeran, im also using libav* for remote files
[00:21] <Daemon404> you *can* seek in remote files over http
[00:21] <Plorkyeran> you could write something with ffms's api that supports streaming, but the innards would have to be pretty different
[00:22] <Daemon404> generally i want to grab the Nth frame on some remote file via https
[00:22] <Daemon404> without dling the whole thing
[00:22] <Daemon404> i had to write a custom thing for that
[00:24] <Daemon404> ffms2 would be able to support that with very little effort i think
[00:24] <Daemon404> depending on how much it needs to dl for indexing
[00:26] <Plorkyeran> it has to parse the video frames for things like repeat_pic and vp8 hidden frames so sorta depends on how little you can get away with feeding the parsers
[00:26] <Daemon404> sounds expensive
[00:27] <Daemon404> ill just stick my custom-rolled thing for now
[00:27] <Daemon404> (rather than attempt to impl it in ffms2)
[00:50] <beastd> bye...
[01:23] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:caa7a494817f: avformat/utils: fix memleak with nobuffer
[01:45] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:b45b1d7af93b: MAINTAINERS: Add some maintainers for parts of libavutil
[02:45] <BBB> ubitux: ok afaics all bugs in the first keyframe of that sample I made are b/c of missing idct32 (or some secondary derivative thereof), so I'll wait for your patch before doing anything more... maybe I'll work on bw adapt in the mean time, or loopfilter, or so
[02:45] <BBB> still have a few directional intra32x32s to write also
[02:45] <BBB> ...
[02:45] <BBB> anyway it's looking somewhat ok at this point
[08:19] <cahit> ffmpeg can't finish avformat_open_input (it never returns) for shout cast 1.9.9beta servers. (example server: 95.211.60.38), gdb only prints "0x00007fff90282f96 in poll ()" when I hit ctrl+c
[08:20] <cahit> correction for the example server: http://95.211.60.38:6006
[09:51] <Datalink> http://illogicallabs.com/paste/00000006.txt
[09:51] <Datalink> I'm starting to feel the urge to give up on trying to make this connect
[10:44] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:81f4d55c3669: MAINTAINERS: alphabetical sort
[10:44] <cone-876> ffmpeg.git 03Stephen Hutchinson 07master:f277d6bf4232: avisynth: Cosmetics
[10:44] <cone-876> ffmpeg.git 03Stephen Hutchinson 07master:9db353bc4727: avisynth: Exit gracefully when trying to serve video from v2.5.8.
[11:22] <zidanne> Why would one get this error while compiling for arm? libavcodec/arm/mdct_vfp.S:114:unknown register alias 'TCOS_D0_HEAD'
[12:04] <cone-876> ffmpeg.git 03Martin Storsjö 07master:f542dedf7209: rtspenc: Check the return value from ffio_open_dyn_packet_buf
[12:05] <cone-876> ffmpeg.git 03Stephen Hutchinson 07master:7f43a09da7b5: configure: Add -lstdc++ to the requirements for linking with libgme.
[12:05] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:5d08f8149c11: Merge commit 'f542dedf72091af8e6f32a12bd64289c58857c21'
[12:12] <cone-876> ffmpeg.git 03Martin Storsjö 07master:62572435d410: rtpenc_chain: Check for errors from ffio_fdopen and ffio_open_dyn_packet_buf
[12:12] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:6bf6d6ad498d: Merge commit '62572435d4106098c090fb8f129a9090e41ff1eb'
[12:23] <cone-876> ffmpeg.git 03Kostya Shishkov 07master:f544c586364e: deprecate AV_CODEC_ID_VOXWARE and introduce AV_CODEC_ID_METASOUND instead
[12:23] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:e4eab2d9bde3: Merge remote-tracking branch 'qatar/master'
[12:38] <michaelni> zidanne, is this with apples toolchain on a mac ?
[12:38] <zidanne> yes
[12:40] <j-b> gas-pp
[12:42] <zidanne> I have gas-pp. You mean that it should get updated?
[12:42] <zidanne> with the new/missing instructions?
[12:52] <michaelni> zidanne, try: https://github.com/michaelni/gas-preprocessor
[12:54] <michaelni> (above contains a few fixes from martin, iam not sure why yuvi hasnt merged them)
[12:56] <zidanne> michaelni: thanks, it worked very well.
[12:57] <michaelni> Yuvi, please merge martins fixes (see above they are needed)
[14:01] <durandal_1707> someone availabe for testing single patch?
[14:02] <ubitux> durandal_1707: ah you wanted someone to test the threading for superx2sai?
[14:02] <durandal_1707> yes
[14:02] <ubitux> do you have it in a branch?
[14:03] <durandal_1707> and benchmark, i like benchmarks
[14:03] <durandal_1707> ubitux: there is patch on ml
[14:07] <durandal_1707> and how its quality compares to hxn2 something
[14:18] <ubitux> durandal_1707: if you want me to test, just push it in a branch
[14:18] <ubitux> it will save me some time
[14:19] <durandal_1707> but you just fetch patch and do git am patch
[14:19] <ubitux> i don't have a copy of the mail
[14:19] <ubitux> and it requires me to dive through archives etc
[14:20] <durandal_1707> i pushed it into super brach
[14:20] <durandal_1707> *branch
[14:21] <ubitux> thx
[14:29] <ubitux> doesn't look faster but maybe i'm doing something wrong
[14:31] <ubitux> durandal_1707: http://pastie.org/pastes/8215033/text
[14:32] <ubitux> (-mt is a build with your patch, and no -mt is a build with your branch HEAD^)
[14:32] <nevcairiel> uses more cpu though =p
[14:33] <ubitux> yes
[14:33] <ubitux> with -mt, all the cpu are indeed in use, but most of the time 50% of them
[14:33] <nevcairiel> is the decoder fast enough to give it enough to do?
[14:34] <ubitux> http://ubitux.fr/pub/pics/_ff-super2xsai-nomt.png
[14:34] <ubitux> http://ubitux.fr/pub/pics/_ff-super2xsai-mt.png
[14:35] <ubitux> nevcairiel: dunno
[14:36] <ubitux> i'm using a random relevant material for the filter: http://archive.org/download/pokemonblue-tas-mrwint/pokemonblue-tas-mrwint.mkv
[14:38] <ubitux> http://pastie.org/pastes/8215054/text
[14:38] <ubitux> not better with that one
[14:38] <ubitux> source: http://www.archive.org/download/AParticularlyFishyDump/pokemongold-tas-fractalfusion.mp4
[14:41] <durandal_1707> perhaps it fight with decoder threads?
[14:42] <ubitux> feel free to propose different cmd line testing
[14:44] <durandal_1707> well the same one with which yadif filter gives performance gains
[14:44] <durandal_1707> or fade filter
[14:46] <ubitux> it would be cool to have some information about threading in the log
[14:46] <ubitux> like where it is enabled/supported
[14:48] <nevcairiel> how fast is the filter single threaded? because yadif can be relatively slow, so the speed up is easier measurable
[14:49] <nevcairiel> personally i also had better experience looking at the fps from the stats output during transcoding
[14:49] <nevcairiel> time seems rather odd sometimes
[15:14] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:5cd57e8758e3: avcodec/jpeg2000dec: check sample sepration for validity
[15:18] <ubitux> michaelni: "separation"
[16:41] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:2960576378d1: avcodec/g2meet: fix src pointer checks in kempf_decode_tile()
[17:08] <BBB> ubitux: how's idct32 going? :)
[17:09] <ubitux> still working on it :p
[17:09] <ubitux> please wait a little more :)
[17:09] <ubitux> got some unexpected events today, so couldn't progress as wanted
[17:26] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:731f7eaaade4: ff_flac_parse_picture: assert that len is within the array
[17:26] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:d0a882ab1d2a: avformat/oggparsevorbis: fix leak of ct
[17:26] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:f3b7f4707012: avformat/oggparsevorbis: fix leak of tt
[17:33] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:60ae776d04b6: av_frame_copy_props: fix unintended self assignment
[17:36] <ubitux> it's also easy to get lost in that maze, i hope i won't make any confusion
[17:36] <ubitux> but it's fun :)
[17:48] <saste> sox API is sloppy, anyone wants to take over the sox wrapper?
[18:02] <saste> is robert sykes on this channel?
[18:03] <saste> allright, i'll bother him by email
[18:30] <zidanne> Is this a known issue? Encoding HLS into libmp3lame gives error: Specified sample format s16 is invalid or not supported
[19:16] <cone-876> ffmpeg.git 03Nicolas George 07master:39bb26f91b18: lavu/log: do not skip overwritten lines.
[19:16] <cone-876> ffmpeg.git 03Nicolas George 07master:dd9555e94b14: ffmpeg: remove obsolete workaround in trim insertion.
[19:16] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:b11b7ceb8926: Merge remote-tracking branch 'cigaes/master'
[19:22] <michaelni> zidanne, i dont know of that issue (which doesnt mean its not known) but probably a good idea to open a ticket
[19:41] Action: pippin continous tweaking a new dithering method - wondering if it would be worthwhile to figure out how to make a clean patch; rather than a quick hack that bastardises the error diffusion :]
[19:41] <pippin> http://pippin.gimp.org/dither/
[19:41] <ubitux> oh my sample :D
[19:42] <JEEBsv> :D
[19:43] <pippin> (my current hack is a 7 line diff that hijacks the error diffusion code paths; providing a constant "error" per pixel)
[20:04] <nevcairiel> the bunny clip looks rather odd with that dithering, the colors are wrong and the pattern is very obvious
[20:06] <pippin> the colors are a bit off - but I find the pattern less objectionable than both the bayer and the diffusion
[20:07] <pippin> I suspect the colors being off to either be due to a bug in my ffmpeg integration - ... or a gamma issue
[20:09] <pippin> the thing that I find worst with my method; is the level of detail in deep shadows and bright highlights
[20:09] <pippin> (when the bunny emerges from the cave, and some cloud details)
[20:09] <nevcairiel> the cave is hard to judge because the wrong colors are very obvious in that part
[20:12] <pippin> my real target for this is eink related dithering, but I like the tendencies it is exhibiting
[21:56] <wm4> ubitux: ffmpeg recognizes a microdvd subtitle file as "Tele-typewriter"
[21:57] <wm4> what's especially dumb is that this "Tele-typewriter" format is completely useless fringe bullshit
[22:27] <wm4> ubitux: actually, this looks like microdvd, but with [] instead of {}... possibly mpl2
[22:27] <wm4> mplayer's subreader.c handles it anyway
[23:02] <wm4> ubitux: this is the file: http://sprunge.us/RXNE
[23:04] <ubitux> mplayer supports it as microdvd?
[23:25] <wm4> ubitux: subreader.c detects it as SUB_MPL2
[23:25] <wm4> it even seems to parse it
[23:25] <wm4> although I don't know what's with these lines starting with \
[23:26] <wm4> err, starting with /
[23:26] <ubitux> it's for italic
[23:26] <ubitux> which is handled in lavc/mpl2dec.c
[23:27] <ubitux> lavf/mpl2dec probing might not be working or strong enough in comparison to lavf/microdvd 
[23:27] <ubitux> for that file at least
[23:28] <ubitux> i don't have time to look at it right now, feel free to have a look
[23:29] <wm4> I'm not sure why it wouldn't work
[23:30] <wm4> maybe it'll fail quickly at very small probe sizes, but it should be ok with larger ones
[00:00] --- Thu Aug  8 2013