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

[burek]

[00:03] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:70cd3b8e659c: mmvideo: check horizontal coordinate too
[00:03] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:3ce55d2e32ce: Merge commit '70cd3b8e659c3522eea5c16a65d14b8658894a94'
[00:14] <jamrial> the new cpu-test is also failing in quite a few slots
[00:22] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:a7153444df90: huffyuvdec: check width size for yuv422p
[00:22] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:296b01d7f91f: Merge commit 'a7153444df9040bf6ae103e0bbf6104b66f974cb'
[00:42] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:1b168e3bcf6f: avutil/cpu: fix cpu-test to work with ffmpegs cpuflags syntax
[00:42] <michaelni> jamrial, fixed, anything else ? (as you say "also")
[00:43] <jamrial> i said also after what Daemon404 mentioned about pixelutils
[00:44] <jamrial> but for that matter, fate-cpu is not outputting the list of supported instruction sets like it used to before we merged the libav version of the test
[00:45] <jamrial> i tried making it use runecho() again instead of run(), but it didn't work
[00:48] <michaelni> ubitux, pixelutils is failing on ppc, are you awake/have time ? or should i take a look ?
[00:50] <Daemon404> its failing on windows too
[00:50] <Daemon404> on some compilers
[00:51] <Daemon404> both icl
[00:58] <jamrial> icl and msvc. gcc is fine
[00:58] <jamrial> so probably alignment. again
[01:17] <michaelni> jamrial, posted patch for cpu echo issue
[01:40] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:84ac2f93ca11: avutil/pixelutils: avoid on stack arrays
[01:40] <michaelni> ubitux, maybe fixed
[01:41] <Daemon404> unchecked mallocs
[01:45] <jamrial> michaelni: it works now with both patches, thanks
[01:46] <michaelni> ok, is there any reason that iam missing why they used stderr ?
[01:50] <jamrial> using run() instead of runecho() makes the test "fail" if outputting to stdout
[01:51] <jamrial> libav doesn't have runecho() and probably also doesn't need/care about outputting the values to stdout anyway
[01:56] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:6552b0558a15: avutil/pixelutils: check for malloc failure
[02:07] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:a8689ba87207: tests/fate/libavutil: switch cpu-test back to runecho so its results are vissible
[02:07] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:9101ef6757e9: avutil/cpu: output cpu data to stdout
[02:08] <michaelni> applied the 2 cpu test fixes, i assume noone knows why it went to stderr
[02:56] <jamrial> has anyone seen plepere lately?
[04:00] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:a32e306be3a2: doc/muxers: document which applications are known to need disable_chpl.
[04:28] <cone-118> ffmpeg.git 03Timothy Gu 07master:9f02a2b22400: transcode_aac: fix const return value
[05:44] <Compnn> [23:23] <runeks> Is visualizing motion vectors still supported? mpv crashes for me when I try to play a file with the option --vd-lavc-o=vismv=1
[05:44] <Compnn> another vismv user 
[05:44] <Compnn> thanks michaelni for keeping these features around
[05:45] <Compnn> i didnt know vismv was such a used feature... :)
[09:40] <ubitux> michaelni: thanks for the fixes
[12:46] <cone-167> ffmpeg.git 03Christophe Gisquet 07master:6786848585dc: hevc_deblock: change tc type
[14:38] <cone-167> ffmpeg.git 03Michael Niedermayer 07master:efc4fe9d74a5: avutil/cpu: add aarch64 entries to 2nd table
[14:38] <cone-167> ffmpeg.git 03Michael Niedermayer 07master:fe0157a19ac0: avutil/cpu: Make cpu flag names match between cpu-test and av_parse_cpu_caps() tables
[14:38] <cone-167> ffmpeg.git 03Michael Niedermayer 07master:6b1df5544e8d: avutil/cpu: check av_parse_cpu_caps() table during cpu-test
[15:59] <cone-167> ffmpeg.git 03Michael Niedermayer 07master:305f72aee77b: avcodec: Change get_pixels() to ptrdiff_t linesize
[16:18] <ubitux> michaelni: thx for ptrdiff_t
[16:19] <michaelni> np
[16:46] <michaelni> mraulet, is the "Christophe Gisq (1.3K) [FFmpeg-devel] [PATCH 0/4] Exploit compile-time constant" patchset ok or could this conflict with future things in hevc ?
[16:47] <mraulet> at the moment there is a conflict with arm mc code
[16:47] <mraulet> I need to check it out with the main developper of this code
[16:49] <michaelni> ok, ill wait, please ping me if there are news
[16:52] <mraulet> yes
[18:33] <mark4o> lwn article on ffmpeg in Debian http://lwn.net/SubscriberLink/607591/7190d6c0b7274eb0/
[18:40] <thardin> three months to go only? huh
[18:58] <Daemon404> heh
[18:58] <Daemon404> the article is a bit uh... one sided
[18:59] <Daemon404> "he mplayer video player application has run into trouble due to its being primarily written and tested for ffmpeg rather than libav"
[18:59] <Daemon404> tl: it canibalizes and rapes teh API
[19:00] Action: kierank struggles with ffmpeg asm crashes
[19:01] <nevcairiel> Still on that problem kierank?
[19:02] <kierank> managed to comment out some asm init in float dsp to fix it at work
[19:02] <kierank> but not at work today
[19:02] <kierank> so need to do it again at home
[19:02] <wm4> Daemon404: yep
[19:02] <wm4> Daemon404: most of mplayer's problems with libav is because it's not using it in clean ways
[19:03] <nevcairiel> At least you seem to be close to know which part exactly is broken
[19:03] <wm4> cannibalizes the build system, accesses API internals, ...
[19:04] <wm4> it's also using some deprecated (and removed in Libav API), as well as explicitly ffmpeg-only API
[19:04] <wm4> I can only imagine the dirty hacks distro maintainers used to make it somehow work on libav
[19:05] <JEEB> they just haven't updated it in years :P
[19:05] <JEEB> at least if we are talking about debian-kei
[19:06] <Daemon404> thats fine, its not like mplayer is maintained
[19:06] Action: Daemon404 runs
[19:07] <wm4> reimar even fixes mencoder bugs
[19:16] <kurosu> kierank, did you try to hack the cpu flag reporting so that it doesn't report mmx ? sounds like an emms issue
[19:16] <kurosu> (alternatively, if you know where dsp or float code is used, insert emms_c() appropriately)
[19:17] <Daemon404> i think he went /care and use avresample
[19:17] <kierank> can't use avresample for various reasons
[19:17] <kierank> doesn't seem to be an avr problem anyway
[19:17] <kierank> seems to be float dsp
[19:17] <Daemon404> ah
[19:17] <kierank> swr*
[19:18] <kurosu> another thing with missing emms is sometimes that the thread/program slows down to a crawl
[19:44] <cone-140> ffmpeg.git 03Christophe Gisquet 07master:4e128ab0b1b3: x86: vpx/h264/hevc/mpeg2: share constants
[19:44] <cone-140> ffmpeg.git 03Christophe Gisquet 07master:71db2d08b1f1: x86: better share ff_pw_2
[19:44] <cone-140> ffmpeg.git 03Christophe Gisquet 07master:6622a6cff30f: x86: dwt: better share constants
[19:45] <cone-140> ffmpeg.git 03Christophe Gisquet 07master:51dd80e7510e: x86: diracdsp: reuse constants
[19:45] <cone-140> ffmpeg.git 03Christophe Gisquet 07master:75837e9add4e: x86: sbrdsp/fft: reuse ps_neg constant
[20:36] <cone-140> ffmpeg.git 03Vittorio Giovara 07master:cbc808d726af: jpeg2000: enable 4 component pixel formats
[20:36] <cone-140> ffmpeg.git 03Michael Niedermayer 07master:5836fe20c686: Merge commit 'cbc808d726afdf53d866264722785c1304c17390'
[20:56] <cone-140> ffmpeg.git 03Martin Storsjö 07master:ed6d9ce914d5: configure: Include the armcc build number in the compiler identification
[20:56] <cone-140> ffmpeg.git 03Michael Niedermayer 07master:40a820d6d865: Merge commit 'ed6d9ce914d552eeda16af857da97c4b1aea1e3f'
[22:08] <ubitux> > All of the code from libav is merged into FFmpeg without credit
[22:08] <ubitux> lol @ diego
[22:10] <ubitux> and then advertising for a dead project (mplayer2) geez
[22:12] <jamrial> is this about debian?
[22:12] <ubitux> jamrial: Diego's long comment on lwn.net
[22:17] <ubitux> about the "All of the code from libav is merged into FFmpeg without credit or thanks", if anyone with a lwn account could tell him that the commit merges keep full authorship of everything and that we even mention them in the 2nd paragraph of our release notes ?
[22:18] <Daemon404> im not touching this article with a 10 foot pole
[22:18] <Daemon404> idiots, idiots everywhere, on all sides.
[22:18] <wm4> ubitux: diego only wrote "Just check out the homepages of mpv http://mpv.io/ and mplayer2 http://www.mplayer2.org/ and see for yourself."
[22:18] <ubitux> wm4: see further
[22:19] <wm4> I'm not sure, maybe the mpv one is too hipster
[22:19] <ubitux> > Forget MPlayer, its successor mplayer2 and mpv, the successor of mplayer2, are much better.
[22:19] <wm4> aha
[22:19] <wm4> if I read that right, he advertises mpv over _two_ dead projects
[22:20] <ubitux> he's saying mplayer2 (and mpv) are better because they build with libav :)
[22:20] <beastd> hi
[22:20] <wm4> have you ever seen the shit MPlayer does
[22:20] <ubitux> he just forget to mention that mplayer2 is not maintained while mplayer still is
[22:21] <wm4> I know you made some patches
[22:21] <wm4> but did you ever go deep down the sources
[22:21] <ubitux> kind of
[22:21] <wm4> there are things that can scare a man for life
[22:21] <ubitux> i'm not saying it's the best software in the world
[22:21] <ubitux> the problem is just that mplayer2 is dead and not maintained
[22:21] <beastd> And that makes mplayer2 much better, of course :)
[22:21] <wm4> I mean not to belittle the greatness of mplayer, but it's a thing from the past
[22:22] <wm4> and mplayer2 is just dead
[22:22] <beastd> wm4: that is exactly the point
[22:22] <beastd> wm4: mplayer is mplayer
[22:22] <ubitux> there is still at least one developer on mplayer which you can poke if you have a security issue or a regression and get it fixed
[22:22] <ubitux> so it's maintained
[22:22] <Timothy_Gu> where's Diego's post?
[22:22] <ubitux> Timothy_Gu: lwn.net
[22:22] <wm4> on the bottom
[22:23] <ubitux> beastd: do you have an lwn account?
[22:23] <Timothy_Gu> oh shit on lwn's title page?
[22:23] <beastd> no, but i have read the lies from DonDiego is spreading there
[22:23] <ubitux> Timothy_Gu: http://lwn.net/SubscriberLink/607591/7190d6c0b7274eb0/
[22:23] <beastd> and the really good article of Jonathan Corbet
[22:24] <ubitux> well just a summary
[22:24] <ubitux> i just would like to fix the "All of the code from libav is merged into FFmpeg without credit or thanks" which is totally wrong
[22:24] <wm4> ubitux: well it's somewhat true
[22:24] <beastd> Interesting, I would say git merge usually preserves author ship of the commits
[22:24] <ubitux> i'm repeating myself but someone needs to tell him the commit merges keep full authorship of everything (even when we don't merge) and that we even mention them in the 2nd paragraph of our release notes
[22:25] <wm4> ffmpeg will announce support for feature X, but never tell that feature X was in fact implemented by Libav
[22:25] <ubitux> wm4: look at our release notes
[22:25] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES;hb=489d066
[22:25] <jamrial> yeah, you could say every other point is subjective, but that comment is objectively and absolutely wrong
[22:25] <ubitux> we do, and every external commit is a merge
[22:25] <wm4> ubitux: ok
[22:25] <ubitux> er last sentence badly worded
[22:25] <wm4> I'm pretty sure this didn't always happen
[22:26] <wm4> does ffmpeg still change the copyright headers of new files merged from libav?
[22:26] <ubitux> i think we don't really care about this
[22:26] <ubitux> libav does it at least
[22:26] <Timothy_Gu> ubitux: thx
[22:27] <nevcairiel> Libav removes copyright lines because its considered trivial files. :P
[22:27] <wm4> yeah
[22:27] <wm4> except when it's their own copyright
[22:27] <jamrial> both projects change "ffmpeg" with "libav" and vice versa for every file. libav however sometimes removes author names (especially when moving code to new files), whereas ffmpeg doesn't
[22:28] <wm4> and Diego is also right in that Libav has done massive cleanups
[22:28] <wm4> they've broken the API a lot, but in turn we have things like AVFrame refcounting
[22:28] <wm4> I see no such developments on ffmpeg
[22:28] <ubitux> aside dropping feature and reindenting, you have the ref counting and what else?
[22:29] <wm4> in fact, mini even asked on the ML whether to merge AVFrame refcounting at all
[22:31] <ubitux> i'm fine admitting ref counting is kind of a good thing (at least if you omit a few details such as squashing everything in a single commit), but can you mention much of other things?
[22:31] <beastd> wm4: asking wether to merge the ref counting was of course the right thing to do. what is wrong with asking your development community about opinions???
[22:31] <ubitux> wm4: there isn't that much "cleanups"
[22:31] <ubitux> wm4: i remember BBB cleanup swscale on libav side though
[22:32] <wm4> beastd: nothing, I'm just saying that ffmpeg was being quite conservative against such large changes
[22:32] <nevcairiel> K&R all the way!
[22:32] <wm4> <ubitux> wm4: there isn't that much "cleanups" <- it all adds up
[22:32] <ubitux> wm4: it's not like it was exactly trivial :)
[22:32] <beastd> nevcairiel: yes and that is hell! never call that a real code cleanup
[22:32] <ubitux> wm4: yes, it makes 2
[22:32] <wm4> part of why ffmpeg is still "better" than Libav is _because_ ffmpeg merges everything from Libav
[22:32] <wm4> otherwise there's a good chance that Libav would have "won"
[22:33] <ubitux> and because we add some great things above too maybe?
[22:33] <jamrial> i thought making big changes (like ref counting was) on our side alone while libav doesn't means breaking (or making difficult) the drop-in compatibility
[22:33] <jamrial> which is why such big changes never start in ffmpeg
[22:33] <wm4> ubitux: some... I'm fond of subtitle and filter additions, which allowed me to delete scary mplayer code
[22:34] <jamrial> we basically let libav take the API wheel to make downstream life easier
[22:34] <beastd> jamrial: unfortunately :(  that is exactly the downside of merging everything from Libav
[22:34] <ubitux> wm4: note that we are blocked about api evolution somehow, not because we are "conservative" but because it can introduce conflicts with Libav in the future
[22:34] <wm4> things like vlc do much better with their own subtitle support etc., though
[22:34] <ubitux> wm4: that is one of the reason we can't really do evolution to subtitles
[22:34] <ubitux> typically
[22:35] <wm4> well Libav subtitle support is a complete joke, so I'm not sure why to keep compatibility for _that_
[22:35] <ubitux> because we still have people using AVSubtitle
[22:35] <nevcairiel> If everyone does their own though, upstream never improves. So kinda it sucks every time vlc develops something internally instead of contributing instead. :p
[22:35] <cone-140> ffmpeg.git 03Michael Niedermayer 07master:7a34b7d80f35: avcodec/dca: Make ff_dca_convert_bitstream() available to libavformat, needed for dts_probe()
[22:35] <cone-140> ffmpeg.git 03Michael Niedermayer 07master:6a4469974650: avformat/dtsdec: check more of the dca headers in dts_probe()
[22:36] <ubitux> wm4: but you did keep subreader.c no?
[22:36] <ubitux> (for compat with libav)
[22:36] <wm4> ubitux: yes, also utf-16 (I know...)
[22:36] <ubitux> :)
[22:37] <ubitux> wm4: one good example for api limitation is the matroska demuxer
[22:37] <ubitux> you know that we still don't export them?
[22:37] <ubitux> i mean, verbatim
[22:37] <wm4> you mean the ASS packet format?
[22:37] <ubitux> i'm pretty sure vlc for example will break as soon as it will uses avformat demuxer for mkv
[22:37] <ubitux> because it has parsing for it last time i looked
[22:37] <wm4> wut, vlc has its own mkv demuxer
[22:38] <wm4> for a reason
[22:38] <ubitux> wm4: it also has avformat (optional) support somehow iirc
[22:38] <jamrial> nevcairiel's lav filters also use its own demuxer (wrapper for mkvparser afaik)
[22:38] <wm4> sure, vlc probably uses it for obscure formats where it didn't NIH something yet
[22:38] <jamrial> nobody seems to like lavf's matroska demuxer :P
[22:38] <nevcairiel> Speaking of breaking things, libav wants to bump. Perfect time to change the output of ass ;)
[22:39] <wm4> jamrial: I think it got better recently, but it still lacks support for some weird matroska features
[22:39] <jamrial> afaik all the new developments were added
[22:39] <wm4> nevcairiel: AFAIK it's bound to the bump
[22:39] <ubitux> nevcairiel: except they won't
[22:39] <jamrial> matroska v4 elements are all supported
[22:39] <wm4> jamrial: ordered chapters, editions
[22:39] <nevcairiel> It's old features that are missing
[22:39] <jamrial> ah, i see
[22:40] <wm4> these are not so easy, because they break the demuxer abstraction
[22:40] <ubitux> don't we have stuff like hls demuxer
[22:40] <ubitux> that basically do the same thing?
[22:40] <wm4> I'm not very fond of how HLS is implemented
[22:40] <wm4> it breaks player caching
[22:41] <nevcairiel> Haalis mkv parse code is a terrible mess as well. It uses alloca and setjmp all the time. But it parses the right things and was easy to wrap, so meh
[22:41] <jamrial> if libav wants to bump we should take the chance to make some cleaning asap
[22:41] <wm4> ubitux: and in fact, there was a patch years ago that makes lavf implement ordered chapters in a way HLS works today
[22:41] <ubitux> yes
[22:42] <ubitux> i would love ordered chapters in mkv
[22:42] <wm4> anyway, I'd be fine if lavf would just export the list of segments, and leave the rest to the player... then I could drop my internal demuxer
[22:42] <wm4> elenril even had a patch for something similar
[22:43] <ubitux> i think i already asked but i supposed the AVChapter are not enough?
[22:44] <wm4> currently, no
[22:44] <nevcairiel> There is a whole boatload of special conditions in that stuff, and no spec (other than it works in Haali Splitter), it took quite a while to get it to a point where I don't get complaints anymore
[22:45] <ubitux> AVChapter can't be extended to export more information?
[22:45] <wm4> nevcairiel: I guess it's easier if you do it on a higher level
[22:45] Action: ubitux wonders if having a filename in AVChapter->metadata would do it :-°
[22:45] <wm4> matroska can have per-chapter metadata
[22:45] <ubitux> oh well.
[22:45] <nevcairiel> Well I kinda did, by wrapping multiple of the haali parser lib
[22:45] <wm4> you'd get clashes
[22:46] <ubitux> ok
[22:46] <wm4> ubitux: http://git.khirnov.net/cgit.cgi/libav/log/?h=playlists
[22:46] <wm4> especially http://git.khirnov.net/cgit.cgi/libav/commit/?h=playlists&id=bb611e5a6620da2883fbf0114bccd1a1628e91e3
[22:46] <wm4> though that ignores editions and all that stuff
[22:49] <ubitux> on a totally unrelated note, i can't fucking find a way to transform "a*x + a*y + z" into "a*(x + y) + z" with any py library
[22:50] <ubitux> and that blocks me to generate a sane dct code >:(
[00:00] --- Thu Aug  7 2014