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

[burek]

[00:35] <llogan> baptiste: greetings and salutations
[04:02] <cone-903> ffmpeg.git 03Anton Khirnov 07master:a553c6a347d3: lavc: use buf[0] instead of data[0] in checks whether a frame is allocated
[04:02] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:56e122787e73: Merge commit 'a553c6a347d3d28d7ee44c3df3d5c4ee780dba23'
[04:10] <cone-903> ffmpeg.git 03Tim Walker 07master:37a3cac78c6b: dcadec: simplify an expression
[04:10] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:8540368582fe: Merge commit '37a3cac78c6b13dc4e2c4f33ef53eed722d6f7b9'
[04:15] <cone-903> ffmpeg.git 03Tim Walker 07master:69d4dbfd1faa: aac_ac3_parser: simplify an expression
[04:15] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:32ab5b82f4b4: Merge commit '69d4dbfd1faa99563065329656bbe597d612ca03'
[04:24] <cone-903> ffmpeg.git 03Kostya Shishkov 07master:16e7b189c548: mpegvideo: Fix swapping of UV planes for VCR2
[04:24] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:0dd8e96b32b2: Merge remote-tracking branch 'qatar/master'
[06:02] <wm4> michaelni: why in the flying fuck is AVFMT_FLAG_KEEP_SIDE_DATA not the default? IMHO this is 1000% broken
[07:51] <jedir0x> so how about that libavfilter sample :)
[07:51] <jedir0x> is there any more documentation other than the doxygen stuff and the sample for implementing filters?
[07:59] <wm4> jedir0x: ffmpeg.c and ffplay.c
[07:59] <wm4> unfortunately
[08:00] <ubitux> wm4: don't you have an example in mpv?
[08:00] <ubitux> :-°
[08:00] <wm4> ubitux: uh, not really, it's just a usage?
[08:01] <wm4> and it does awkward stuff to connect two filter chains
[08:01] <ubitux> to add to the confusion, the examples are still broken
[08:01] <ubitux> :(
[08:02] <wm4> is the example at least marked as broken?
[08:10] <ubitux> yes, in the trac 
[08:11] <ubitux> :(
[08:11] <ubitux> it seems nicolas & stefano are not motivated to fix it
[08:12] <wm4> "in the trac"
[08:12] <wm4> nobody looks there
[08:12] <wm4> doesn't it cause you physical pain that users will just copy&paste the incorrect example into their code?
[08:20] <ubitux> wm4: it does
[08:20] <ubitux> definitely
[08:22] <wm4> at least adding a big fat warning to the example itself would perhaps be helpful
[08:23] <nevcairiel> what i cant help but wonder,where the examples ever correct and just aged over time and got outdated, or were they wrong from the start? :p
[08:24] <wm4> in the lavfi case, I'd expect they were not converted correctly to the new API
[09:48] <plepere> assembly question
[09:49] <plepere> I have mx as a function argument. I whish to access  ff_hevc_epel_filters[mx - 1]. ff_hevc_epel_filters is declared in hevcdsp.h 
[09:50] <plepere> how can I access the table in assembly ?
[09:51] <nevcairiel> add "cextern ff_hevc_epel_filters" at the top of the file (in RODATA)
[09:51] <plepere> I doubt that a simple movb r0,[ff_hevc_epel_filters+mx-1] works
[09:51] <nevcairiel> once you have done that, it should work
[09:51] <plepere> ok, and I must add the include hevcdsp.h too ?
[09:52] <nevcairiel> no
[09:52] <plepere> ok
[09:52] <plepere> thank you
[09:52] <nevcairiel> actually, don't include the ff_
[09:52] <nevcairiel> its added automatically again
[09:52] <plepere> ok
[09:52] <nevcairiel> example usage can be found in h263 loopfilter asm
[09:53] <plepere> awesome, thanks
[10:23] <ubitux> ok i fixed the example
[10:23] <ubitux> but i cheated
[10:29] <ubitux> this code should work, but it doesn't&
[10:33] <cone-128> ffmpeg.git 03Clément BSsch 07master:1f7b7d544717: doc/examples: fix mem issues in filtering_video.
[10:40] <durandal11707> saste: working on another filter?
[10:41] <saste> durandal11707, not at the moment
[10:41] <saste> i'll probably work on perlin and lua if time/motivation allow
[10:42] <ubitux> hey saste, about the binding
[10:42] <ubitux> what about just writing a simple high level api on top of a few libraries?
[10:42] <ubitux> mkdir libsimpleffmpeg
[10:43] <ubitux> we could discuss the features we need
[10:43] <saste> ubitux, just ... simple ...
[10:43] <saste> it's not really that
[10:43] <ubitux> we don't need to provide much things at first
[10:43] <saste> also i'm not really sure that will help
[10:44] <ubitux> also, we could also just mkdir python, and write a C binding
[10:44] <saste> the point is, if you have a binding, writing a high-level API (for your scripting language) is easier than writing it in C
[10:44] <saste> there is already pyffmpeg
[10:44] <ubitux> merge it \o/
[10:45] <wm4> merge ffms2
[10:45] <ubitux> saste: pyffmpeg is doing like everyone else
[10:45] <ubitux> it's calling ffmpeg.
[10:46] <ubitux> i was more into proposing a real binding, with language specific idioms
[10:53] <durandal11707> oh dear, why it is so fucking complicated to call specific filter for specific frame?
[10:53] <durandal11707> and, enable=expr is not solution
[10:53] <ubitux> :)
[10:54] <ubitux> because filters have context
[10:54] <ubitux> and because they can keep or vomit N frames when you feed one
[10:59] <durandal11707> yes, but i'm not talking about such filters....
[10:59] <ubitux> would you want a pure callback for filters doing a 1-to-1 filtering?
[11:01] <durandal11707> imagine you want to do simple retarded slideshow transition with blend filter
[11:08] <saste> https://github.com/Wessie/python-ffmpeg
[11:08] <saste> there is also this one, but seems a bit like vapourware
[11:09] <ubitux> "These bindings might never be finished!"
[11:09] <ubitux> 10 mths ago
[11:09] <ubitux> nice
[11:15] <plepere> to  set a register to a specific value, is it better to create a table elsewhere and move from memory or is there another way ?
[11:15] <plepere> I want to set m1 to (6, 5, 4, 3, 5, 4, 3, 2, 4, 3, 2, 1, 3, 2, 1, 0) for instance
[11:18] <plepere> should I simply define in RODATA like rnd_rv40_2d_tbl in h264_chromamc ?
[11:19] <ubitux> probably yes
[11:21] <plepere> ok thanks
[11:47] <cone-128> ffmpeg.git 03Michael Niedermayer 07release/2.1:607e5038a9a5: avcodec/pcm-dvd: fix 20bit 2 channels
[11:47] <cone-128> ffmpeg.git 03Michael Niedermayer 07release/2.1:87c416d93a09: avcodec/pcm-dvd: fix 20/24bit 1 channel
[11:49] <cone-128> ffmpeg.git 03Martin Storsjö 07master:fa48be9b954a: configure: Don't use symlinks for creating the out of tree makefile
[11:49] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:b31587af4b07: Merge remote-tracking branch 'qatar/master'
[11:49] <durandal11707> michaelni: put that pcm-dvd into more coverage
[12:26] <ubitux> michaelni: about the jacosub failure, how should i interpret it?
[12:29] <michaelni> jacosub ?
[12:30] <ubitux> yes the probing issue
[12:30] <ubitux> you raised a while ago
[12:30] <ubitux> with probetest, at size=16
[12:30] Action: michaelni runs memtest /dev/brain
[12:30] <ubitux> 14:33:54 < michaelni> ubitux, probetest says: Failure of jacosub probing code with score=51 type=1 p=CAB size=16
[12:30] <ubitux> 14:34:12 < michaelni> thats  tools/probetest 8192 500000
[12:31] <michaelni> yes
[12:31] <ubitux> what does this output mean and what can i do to fix it?
[12:32] <michaelni> the output means that for random input jacosub was detected with core of 51
[12:32] <michaelni> Score
[12:32] <ubitux> mmh
[12:38] <ubitux> michaelni: can i see what input is tested?
[12:40] <michaelni> that should be easy to add to probetest
[12:40] <wm4> michaelni: why is side data "merged" by default?
[12:40] <michaelni> ubitux, and should be quite usefull feature
[12:41] <wm4> (when demuxing)
[12:42] <michaelni> if side data isnt merged then applications that arent AVPacket based would break. The merging sort of keeps the same ABI working 
[12:42] <wm4> what if an application uses libavformat but its own decoding? then lavf will corrupt the packats by adding side data
[12:43] <wm4> also side data has been around for a very long time, before this merging was introduced
[12:43] <wm4> libav just does fine with it
[12:43] <wm4> and btw., this si an libav ABI incompatibility
[12:43] <wm4> what if someone uses ffmpeg libavformat and libav libavcodec?
[12:44] <wm4> also, if some raw data contains the merge marker at the end of the packet, random things happen
[12:44] <wm4> I seem to be able to come up with 1000 reasons why this side data merging and splitting is an extremely bad idea
[12:45] Action: ubitux is more worried about slowliness
[12:45] <ubitux> hopefully we don't use them much
[12:45] <michaelni> "what if an application uses libavformat but its own decoding?" if it doesnt support side data it likely wont work, as the data is likely there for a reason
[12:46] <ubitux> Failure of jacosub probing code with score=51 type=1 p=CAB size=16
[12:46] <ubitux> 00000000  40 37 40 30 93 01 48 e0 09 96 10 90 78 0f 0c 10 @7 at 0..H.....x...
[12:46] <ubitux> sounds like a legit file :))
[12:46] <ubitux> (@<frame> @<frame>)
[12:46] <ubitux> maybe i could check for increment
[12:47] <michaelni> "libav just does fine with it", maybe, maybe not, has someone done proper tests on that?
[12:48] <michaelni> "and btw., this si an libav ABI incompatibility" and the other way around breaks ABI to previous ffmpeg & libav
[12:49] <michaelni> "what if someone uses ffmpeg libavformat and libav libavcodec?", this wont work as libav libs are not drop in replacements for ffmpeg libs
[12:49] <michaelni> "also, if some raw data contains the merge marker at the end of the packet, random things happen", elaborate please, what things?
[12:49] <wm4> sorry but you're full of shit
[12:49] <wm4> you keep adding ABI hacks so that ffmpeg is a drop-in replacement for libav
[12:49] <michaelni> wm4 "I seem to be able to come up with 1000 reasons" <-- this is hit
[12:49] <michaelni> Shit
[12:50] <wm4> so if you have some data, e.g. from a raw demuxer, it could contain the merge marker at the end of the packet, and then libavcodec would try to interpret that as side data
[12:51] <michaelni> if theres a problem we should fix it, and if the merging is a problem we should change it with the next ABI bump, that is if its better not to merge
[12:51] <wm4> so you could probably construct a file that fails to play with ffmpeg, but works fine with libav
[12:51] <wm4> what if users actually want to access the side data?
[12:53] <michaelni> "so you could probably construct a file that fails to play with ffmpeg, but works fine with libav", yes you can construct that probably, and id guess you can do that probably for any 2 non trivial programs unrelated to multimedia too
[12:54] <michaelni> if the user wants to access the side data, she can set the flag that disables merging or split it out, is this a problem for some use case ?
[12:54] <wm4> it requires setting yet another mysterious flag - that is not needed on Libav, because Libav doesn't do this insane crap
[12:55] <cone-128> ffmpeg.git 03Clément BSsch 07master:722fb81dc5c8: avformat/jacosubdec: make probing less tolerant.
[12:55] <ubitux> michaelni: fixed
[12:55] <michaelni> ubitux, thx
[12:57] <michaelni> wm4, yes, there are applications for which the merged data is simpler to handle and some for which the split data is. The question is which way is overall more convenient and does overall cause fewer problems
[12:58] <michaelni> are there any bug reports for either variant causing problems ?
[13:04] <ubitux> about sws nv12 ’ yuv420p:
[13:04] <ubitux> 12:59:28 <+kierank> Because it always calls hscale 
[13:04] <ubitux> 12:59:28 <+kierank> Because its a piece of shit
[13:04] <ubitux> 12:59:50 <+kierank> It does a "scale" with 2^n, 0,0,0
[13:04] <ubitux> 12:59:57 <+kierank> And the shifts down
[13:04] <ubitux> 13:00:13 <@elenril> because it looked like a good idea at the time?
[13:04] <ubitux> 13:00:28 <+kierank> Be damned if I know
[13:04] <ubitux> might be relevant to discuss here as well ^
[13:05] <ubitux> (because i'm curious about that too)
[13:10] <Compn> what do you want it to scale first ?
[15:13] <ubitux> michaelni: careful when merging the recent cosmetics
[15:13] <ubitux> they dropped some ( ) protecting around args in macros
[15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:ef627bf9ecdd: swscale: add nv12/nv21->yuv420 converter
[15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:94d7ca2b58af: swscale: fix used stride in planarToNv12Wrapper()
[15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:4729b529e60f: swscale/x86/rgb2rgb: extend framework to also include AVX
[15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:1de064e21e7f: swscale/x86/rgb2rgb: change cpu optim identifiers to lower case
[15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:3033cd755592: swscale/x86/rgb2rgb_template: add mmx/sse2/avx optimized deinterleaveBytes
[15:21] <ubitux> oh wow
[15:21] <ubitux> some michaelni speed awesomeness
[15:22] <JEEB> nice
[15:58] <ubitux> michaelni: and now you add http://git.videolan.org/?p=vlc.git;a=commitdiff;h=5d15f59a0e726adad5bc86b1594d5443780b16b9 ? :)
[16:00] <michaelni> yes that should be ported, yes
[16:02] <michaelni> i might look into it but my todo list is long ...
[16:02] <ubitux> michaelni: well, afaict from today your todo list is quite flexible :)
[16:52] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:8769113accf1: mpeg4videoenc: K&R formatting cosmetics
[16:52] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:18df75fa2fe2: Merge commit '8769113accf1f3b78634dec60b37f7354ed6d88d'
[17:28] <Daemon404> looking at the icl failures...
[17:28] <Daemon404> finally.
[17:58] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:d234c7a07c13: mpeg4videodec: K&R formatting cosmetics
[17:59] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:2c6e693c9754: Merge commit 'd234c7a07c1313fd215e8e242492bf71f5f3321e'
[18:07] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:c673fc919c37: hevc_sei: drop unused parameter
[18:07] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:8983dea426e3: Merge commit 'c673fc919c374c60b1e6d80d8822712eadf67f16'
[18:19] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:3a16ec19d242: vf_interlace: check one av_frame_clone allocation
[18:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:0a382aa99bd2: Merge commit '3a16ec19d2426457419cb8a7304f97982699efda'
[18:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:6a71efff33e7: avfilter/vf_tinterlace: check clone return value
[18:30] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:6f1ec8edf241: avcodec.h: include version.h before using version macro
[18:30] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:066dbfe1655b: Merge commit '6f1ec8edf2416441e2348f3a0915c9fee179d7da'
[20:15] <cone-128> ffmpeg.git 03Compn 07master:ef7f7516426e: riff: add DYM4 mpeg4 fourcc
[20:16] <Compn> chinese broadcasting industry fourcc :)
[20:17] Action: Compn grumbles at the prospect of every single country having 3-4 different fourccs per each main codec (mpeg4, h264, mjpeg, etc)
[20:18] <Compn> michaelni : how about unknown codec probing ?
[20:18] <Compn> think codec probing could be done , similar to demuxer probing ?
[20:20] <Compn> hey its llogan :)
[20:21] <llogan> hey Compn
[20:22] <Compn> i want to remove some excess verbiage from index page of ffmpeg :)
[20:22] <llogan> which verbage? do you have a patch?
[20:23] <Compn> sure
[20:23] <Compn> http://e9b44f1821e394a0.paste.se/
[20:24] <Compn> a bunch of words that say 'click here' , which we already have links to
[20:25] <Compn> probably the last sentence from the top paragraph too.
[20:27] <llogan> i wonder if anyone astucally reads any of that
[20:27] <llogan> *actually
[20:30] <llogan> Compn: ok with me, but you should probably still post the patch on -devel
[20:32] <Compn> nah
[20:32] <Compn> too much to do :)
[20:33] Action: Compn deletes it
[20:34] <llogan> lazy!
[20:35] <Compn> let it be written, let it be done
[20:35] <Compn> (it is done)
[20:35] <Compn> ahhhh much cleaner index page
[20:35] Action: Compn wonders what other diego-talk he can delete from the pages
[20:36] <llogan> It's called "DB formatting".
[20:38] <Compn> want to put twitter or facebook or g+ on 'contact' page ?
[20:38] <Compn> i guess we dont want to do support on those, so no :)
[20:40] <llogan> you could make a "social" or "other" or whatever section
[20:54] <Compn> llogan : did you see that deprecated bugreport is still going ?
[20:55] <Compn> whats the status on that ? :)
[20:55] <llogan> i don't know. i quit caring and can't give ass of rat about debian anymore
[20:56] <llogan> also it gave me a good excuse to get of fof my ass and drop it as the distro for all of my work servers
[20:57] <Compn> maybe i should run with it and initiate plan issue-trademark-cease-and-desist
[20:58] <Compn> must contact fabrice for that
[20:58] <llogan> maybe we can hire mru's lawyer
[20:59] <llogan> (that was a joke)
[21:00] <Compn> i was trying to think of funny reply, but brain is on break right nopw
[21:01] <llogan> heh. latest name in the spam queue: Elfa Kabongo Omar-Bongo
[21:01] <Compn> haha
[21:01] <Compn> sounds kinda racist, but also funny
[22:10] <cone-128> ffmpeg.git 03Diego Biurrun 07master:57f13fd7e993: dv_tablegen: Remove CONFIG_SMALL preprocessor check
[22:10] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:d5d29ae3b037: Merge remote-tracking branch 'qatar/master'
[22:32] <cone-128> ffmpeg.git 03Stephen Hutchinson 07master:69cf626f9c1b: cmdutils: Add -buildconf option.
[22:39] <Zeranoe> I have been notified that there might be some regression with the H.264 decoder in the 2.1 release. I guess something to do with "AVC: nal size". Was there anything changed to the decoder that might cause that?
[22:56] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:f836b0c581f7: swscale/x86: SIMD deinterleaveBytes() depends on YASM
[23:10] <ubitux> michaelni: 69cf626f9c1b is quite a shitty commit
[23:18] <michaelni> ubitux, elaborate please
[23:18] <ubitux> michaelni: strtok/av_strtok, pkg-config hack, obvious non conforming coding style, ...
[23:20] <michaelni> whats the problem with strtok ?
[23:23] <michaelni> about pkg-config, what do you suggest ?
[23:25] <ubitux> michaelni: we have a av_strtok() for that purpose
[23:25] <ubitux> about pkg-config i don't know but that hack likely doesn't handle a lot of cases
[23:26] <saste> strtok -> non portable (mingw or some windows thing)
[23:27] <michaelni> saste, strtok or strtok_r ?
[23:27] <cone-128> ffmpeg.git 03Stefano Sabatini 07master:80e5859d7a00: doc/muxers/segment: remove wrong default indication for segment_list_flags option
[23:27] <saste> strtok
[23:27] <saste> no i mean strtok_r
[23:28] <saste> strtok is non-thread-safe, but probably is not important for ffmpeg
[23:28] <ubitux> gtg, 'night
[23:28] <saste> ubitux, good'
[23:28] <michaelni> ubitux, night
[23:29] <michaelni> anyway i can replace it by av_strtok if prefered?
[23:30] <saste> and yes the commit is *extremely* hackish
[23:31] <saste> also what's the point of the option?
[23:31] <michaelni> i can also revert it if wanted
[23:33] <michaelni> IIRC av_log() cannot handle lines longer than 1024 chars or so
[23:34] <michaelni> also why did noone reply to the patch with these complaints, it was posted in august ...
[23:37] <michaelni> just need to know if revert or "improve" is preferred for 69cf626f9c1b ?
[23:40] <saste> michaelni, what's the point of the patch?
[23:40] <saste> what's wrong with a plain configure line?
[23:41] <michaelni> it can get truncated if its too long
[23:42] <michaelni> also its not very readable
[23:42] <saste> uhm yes
[23:43] <saste> i stumbled against the av_log limitation
[23:43] <saste> are you aware of any efficient way to deal with that?
[23:43] <saste> at some point i was experimenting with printing a context option through AVBprint, but the resulting line was always truncated
[23:49] <michaelni> one could do dynamic mem allocation in av_log() (which needs ENOMEM handling, and probably a mutex) 
[00:00] --- Wed Nov 20 2013