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

[burek]

[01:14] <cone-628> ffmpeg.git 03Michael Niedermayer 07master:8202c49b4362: avformat/utils: do not wait for packets from discarded streams for genpts
[04:05] <cone-628> ffmpeg.git 03Michael Niedermayer 07master:4eb13cdfb0aa: avformat/asfdec: dvrms timestamps are pts not dts
[06:01] <cone-628> ffmpeg.git 03Michael Niedermayer 07master:1e3f77b53a80: swscale/x86/rgb2rgb_template: fix 1 byte overread in yuyvtoyuv420 and uyvytoyuv420
[11:12] <anshul> is it possible to set multiple variable by one command line option
[11:13] <anshul> just now i have seen that only one variable offset is passed with option
[13:33] <cone-319> ffmpeg.git 03Ronald S. Bultje 07master:ebd1c505d22a: h264: fix direct temporal mvs for bottom-field-first poc order.
[14:02] <cone-319> ffmpeg.git 03James Almer 07master:276bef534067: x86/hevc_deblock: add ff_hevc_[hv]_loop_filter_luma_{8, 10}_sse2
[14:04] <anshul> nicolas, compute_edt has no extra latency, for decoder its enabled only when transcoding
[16:18] <cone-319> ffmpeg.git 03Ben Avison 07master:42c1cc35b762: armv6: Accelerate ff_imdct_half for general case (mdct_bits != 6)
[19:23] <j-b> lol @ the smb discussion
[19:23] <j-b> btw, we are writting a new smb library, LGPL and light
[19:24] <wm4> shouldn't you first fix your libdvdnav fork
[19:24] <wm4> before proceeding to fork or replace other libs
[19:25] <j-b> fix?
[19:25] <cone-319> ffmpeg.git 03Star Brilliant 07master:3f815f713bef: AVFormat: LRC demuxer and muxer
[19:25] <j-b> how is it broken?
[19:26] <wm4> there's at least the issue that seeking is worse than mplayer's stream_dvd.c
[19:26] <j-b> wm4: and it's not the fork, but the main official one.
[19:27] <ubitux> j-b: so which one is the downstream?
[19:28] <j-b> there is no downstream
[19:28] <ubitux> :))
[19:28] <j-b> https://github.com/videolabs/libdsm anyway, if you want to have a look
[19:29] <wm4> ah thank apple
[19:29] <wm4> so uh I guess smb:// is useful on iOS
[19:30] <wm4> because even if OSX supports accessing cifs directly, the stalinist restrictions in iOS wouldn't allow using it
[19:30] <Daemon404> i still maintain it should be implemenetd in the layer above lavf
[19:32] <j-b> wm4: indeed
[19:32] <j-b> wm4: Android is the same.
[19:32] <wm4> just after we got rid of DOS, win31, and ancient commercial UNIXes, and Microsoft actually adding C99 support, mobile crap has to come along :(
[19:32] <wm4> and bring much brokenness and NIH
[19:33] <Daemon404> wm4, sandboxing seems reasonable to me.
[19:33] <Daemon404> also google didnt NIH
[19:33] <Daemon404> and oracle sued them
[19:33] <Daemon404> :P
[19:38] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:ccc4324c90ea: MAINTAINERS: Add ubitux for text subtitles
[19:39] <ubitux> heh
[20:05] <wm4> Daemon404: does curl really do smb?
[20:07] <Daemon404> wm4, no, but youll note i used the lib names separately
[20:08] <wm4> even so, I wouldn't be surprised if curl would be open to adding a smb protocol
[20:08] <Daemon404> indeed
[20:09] <Daemon404> "And anyway, what good would it do separate them? I see a lot of trouble
[20:09] <Daemon404> keeping the libraries separate, with endless compatibility problems, and I
[20:09] <Daemon404> see very little benefit."
[20:09] <Daemon404> holy shit
[20:09] <Daemon404> does he not see teh irony in hsi statement
[20:09] <Daemon404> didnt he argue to keep the libav* separate in the past
[20:10] <wm4> yeah
[20:10] <wm4> the funny thing is we see trouble due to keeping the libs "separately" all the time
[20:11] <Daemon404> yep
[20:11] <wm4> (just what for are we doing all this work to keep them "separate"?)
[20:12] <Daemon404> vlc certainly uses them separately
[20:12] <Daemon404> but vlc also doesnt abuse the protocols iirc
[20:12] <Daemon404> (i coukd be mistaken)
[20:13] <ubitux> ffplay is my main video player, so i need smb support in it ;)
[20:13] <Daemon404> you poor bastard
[20:13] <BBB> I always feel that way about linux desktop users
[20:13] <BBB> you poor bastard
[20:13] <Daemon404> i dont mind using linux desktop for development work
[20:14] <Daemon404> its not my day-to-day desktop though
[20:14] <Daemon404> i value my battery.
[20:14] <wm4> so you use iOS instead of Android?
[20:14] <Daemon404> neither are desktops
[20:14] <BBB> and android can barely be described as linux even if you ignored the desktop part
[20:15] <BBB> it happens ot use the kernel, thats about it
[20:15] <Daemon404> a kernel *fork*
[20:15] <BBB> :)
[20:17] Action: Daemon404 ponders the value of a "mplayer devs are not allowed to make design choices" rule
[20:17] Action: Daemon404 runs
[20:18] <Daemon404> oh that reminds me
[20:19] Action: Daemon404 sends a patch to remove a "for mplayer" hack
[20:19] <wm4> oh
[20:20] <wm4> I thought that about gopher was a joke
[20:20] <wm4> but it isn't
[20:20] <Daemon404> no
[20:20] <Daemon404> im not joking
[20:20] <Daemon404> sadly
[20:20] <wm4> I could understand if it was added in 2001 or so (maybe)
[20:20] <wm4> but it was added in 2009
[20:20] <ubitux> :D
[20:20] <ubitux> haters gonna hate
[20:21] <wm4> just so that ubitux can watch video from gopher sources with ffplay
[20:21] <ubitux> ;)
[20:21] <Daemon404> where does one find gopher sources
[20:21] <ubitux> it's true that these 125 lines of code, including LGPL boilerplate are extremely annoying
[20:21] <Daemon404> i dont particularily care if it hangs around
[20:22] <Daemon404> the actually annoying thing is how i constantly hit bugs in ffmpeg's networking code
[20:22] <Daemon404> which wouldnt exist if we just use libcurl :P
[20:22] <Daemon404> i pitched the idea before, but it was uh... not met with enthusiams
[20:23] <wm4> write a patch
[20:25] <Daemon404> i asked before i wrote one and was mostly told not to botehr
[20:31] <Daemon404> man...
[20:31] <Daemon404> git blame libavcodec/utils.c
[20:31] <Daemon404> just sits there, crunching
[20:31] <Daemon404> :D
[20:34] <ubitux> Timothy_Gu: i still think library versions should be on top.
[20:34] <ubitux> not at the end, not in the middle, but on top of the file
[20:34] <ubitux> like, after the intro
[20:35] <Daemon404> i agere with you ubitux 
[20:35] <Daemon404> fwiw
[20:35] <Timothy_Gu> why?
[20:36] <Daemon404> theyre important info and should be up front
[20:36] <Timothy_Gu> API versions aren't supposed to be in the release notes, maybe on the website yes
[20:36] <wbs> :q
[20:36] <Daemon404> says who?
[20:44] <cone-319> ffmpeg.git 03Lukasz Marek 07master:4cc0f79a2c11: lavf: add samba protocol via libsmbclient
[20:50] <Timothy_Gu_> Daemon404, ubitux: do you guys like something like https://gist.github.com/TimothyGu/05abbfc20156737ec624 ?
[20:51] <wm4> Timothy_Gu_: you could mention that there are no breaking changes from 2.2
[20:51] <ubitux> (OptimizationS*)
[20:51] <Daemon404> not even ABI?
[20:51] <wm4> Daemon404: not sure
[20:52] <ubitux> Timothy_Gu: fine with me
[20:52] <Daemon404> that looks pretty OK to me
[20:52] <ubitux> (the weird intro blocks looks a bit weird before the full list but well...)
[20:54] <jamrial> Timothy_Gu: you'll have to add LRC de/muxer and Samba protocol to the list of changes in there
[21:19] <cone-319> ffmpeg.git 03Diego Biurrun 07master:a8552ee3eb33: ppc: dsputil: Coalesce all init files
[21:19] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:98227ba5fa45: Merge commit 'a8552ee3eb335d2fd2d6c99363367a6090298f78'
[21:24] <Compn> ffmpeg does smb now? :)
[21:24] <Compn> nice !
[21:56] <Timothy_Gu> jamrial: thanks for the reminder
[21:57] <iive> smb as in samba protocl, cifs ?
[21:57] <Timothy_Gu> wm4, Daemon404: http://upstream-tracker.org/compat_reports/ffmpeg/2.2.4_to_current/abi_compat_report.html says otherwise
[21:58] <Timothy_Gu> Plus I already said " FFmpeg 2.3 is completely source-compatible to the FFmpeg 2.2 series."
[21:58] <Daemon404> Timothy_Gu, useful/nifty site
[21:59] <Daemon404> Timothy_Gu, it could be wrong in our case
[21:59] <Daemon404> oh, welp
[21:59] <Daemon404> nope
[21:59] <Daemon404> brain derped, its correct
[22:00] <cone-319> ffmpeg.git 03Diego Biurrun 07master:acf91215c74a: x86: dsputil: Avoid pointless CONFIG_ENCODERS indirection
[22:00] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:cc3e7a4c3df9: Merge commit 'acf91215c74a91eb3b86af01dcb1d3c78d0e2310'
[22:05] <Compn> wm4 : btw i need smb support because android / googletv
[22:23] <Compn> [14:17] * Daemon404 ponders the value of a "mplayer devs are not allowed to make design choices" rule
[22:24] <Compn> Daemon404 : if you make ffmpeg - curl wrapper patch probably would be included ;p
[22:25] <Compn> wm4 : cant even get terminal on gtv without buying some app :P
[22:42] <Compn> Daemon404 : still here ?
[22:42] <Daemon404> i am omnipresent
[22:42] <Compn> you said one level up, you mean in the player or in fuse ?
[22:42] <Compn> because you said both and i am confuse.
[22:43] <Daemon404> you need to read the entire chain
[22:43] <Compn> i did, twice
[22:43] <Daemon404> for sanboxed things like phones and devices, player 
[22:43] <Daemon404> i specificall said play fr gtv
[22:43] <Daemon404> if oyu looked
[22:43] <Daemon404> player*
[22:44] <Compn> maybe i'm missing a mail
[22:44] <Compn> and the player i want to use is ... ffplay 
[22:44] <Compn> because vlc doesnt work on gtv
[22:44] <Compn> because gtv is a bastard hack of android
[22:44] <Daemon404> http://ffmpeg.org/pipermail/ffmpeg-devel/2014-July/159830.html
[22:45] <Daemon404> lol you think SDL will work on gtv?
[22:45] <Compn> i'm hoping something will
[22:47] <Compn> so you dont want ffmpeg to reinvent every protocol... are you ok for putting mplayer or vlc's vo modules into ffplay? :)
[22:47] <Compn> ehe
[22:48] <Daemon404> i dont consier "ffplay needs it", to be a good reason for putting stuff inside ffmpeg
[22:48] <Daemon404> ffplay is the bastard growth from a small testing player afaict
[22:48] <Daemon404> <.<
[22:48] <Compn> i figured out the problem the other day btw
[22:49] <Daemon404> ?
[22:49] <Compn> its because mplayer is the main test application for ffmpeg libs :)
[22:49] <Daemon404> it defintely isnt
[22:49] <Daemon404> not anymore
[22:49] <Compn> i mean by devels 
[22:49] <Daemon404> oh
[22:49] <Compn> not ... in use numbers
[22:49] <Daemon404> right
[22:49] <Daemon404> the inbreeding.
[22:50] <Compn> the lack of a small fast compiliable testsuite to test changes 
[22:50] <Compn> with heavy cross compatability
[22:50] <Daemon404> what?
[22:51] <Compn> devels test with mplayer because there is no alternative player ?
[22:51] <Daemon404> vlc?
[22:51] <Daemon404> FATE?
[22:51] <Daemon404> ffplay
[22:51] <JEEB> lörs lärä
[22:51] <Daemon404> ?
[22:51] <Compn> easy to compile on many systems
[22:51] <Daemon404> ... aka vlc?
[22:51] <Compn> >autoconf
[22:51] <Daemon404> i dont see the problem, t works out of the boc
[22:51] <JEEB> if you think mplayer is easy to compile, then I wonder regarding your standards
[22:52] <Daemon404> and is less error prone than players abomination of a configue scripts
[22:52] <Daemon404> mplayer's*
[22:53] <Daemon404> fwiw i always test in ffplay an vlc
[22:53] <Daemon404> and*
[22:56] Action: ubitux smiles stupidly at Daemon404 
[22:56] <Daemon404> ubitux, at least ffplay uses the api right =p
[22:56] <ubitux> :)
[22:57] <ubitux> anyway, it's nice to have all the protocol available in any dumb player such as ffplay
[23:02] <wm4> <Daemon404> ubitux, at least ffplay uses the api right =p <- who knows
[23:02] <Compn> i have doubts
[23:02] <wm4> you have no clue
[23:02] <Compn> ffplay needs multiple input support
[23:02] <Compn> ffmpeg has it
[23:02] <Compn> file input*
[23:03] <Daemon404> wm4, well the API is such that evaluating if it is used correctly is very hard
[00:00] --- Mon Jul 14 2014