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

[burek]

[00:18:31 CET] <Michael92> Hello, I am hoping someoen could help me. I am using this guide https://trac.ffmpeg.org/wiki/CompilationGuide/RaspberryPi to cross-compile ffmpeg for raspberry pi. When I get to the step to compile lbix264 during the make command It is hanging for over 30 minutes on /home/adminuser/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -Wno-maybe-uninitialized -Wshadow -O3 
[00:18:31 CET] <Michael92> -ffast-math  -Wall -I. -I. -march=armv6 -std=gnu99 -fomit-frame-pointer -fno-tree-vectorize   -c -o encoder/analyse.o encoder/analyse.c.. Is this normal if not how do I fix it? 
[00:25:10 CET] <kierank> possibly yes
[00:25:14 CET] <kierank> x264 is slow to compile
[00:26:39 CET] <Michael92> Okay thanks, i guess I will continue to wait.
[00:27:26 CET] <ubitux> more than 30 minutes to compile x264? what
[00:27:37 CET] <ubitux> it takes 9 seconds to compile the whole thing here
[00:27:54 CET] <ubitux> also, it sounds like a question for #x264
[00:28:18 CET] <Michael92> Okay, I am following a guide from ffmpeg so I thought I would try here.
[00:28:23 CET] <ubitux> but your toolchain or i/o are probably the problem
[00:29:07 CET] <kierank> ubitux: not on raspberry pi
[00:29:29 CET] <Michael92> I am not compiling it on raspberry pi, I am on ubuntu cross compiling for raspberry pi
[00:29:52 CET] <kierank> oh
[00:30:26 CET] <Michael92> I probably did something wrong on the guide.. I'll try again tomorrow
[00:32:27 CET] <Michael92> I wish I didn't have to compile my own to use on raspbian.. The one on the repository is giving me errors
[00:36:19 CET] <Compn> >encouraging people to use rpi for ffmpeg 
[00:36:46 CET] <kierank> why not
[00:37:02 CET] <kierank> the new one is quite powerful
[00:37:08 CET] <Compn> i'm talking the old one
[00:37:15 CET] <Compn> which is what 99% of people talking about rpi have
[00:37:27 CET] <Compn> which is what i'm guessing Michael92 has
[00:38:17 CET] <Compn> because imo the first rpi is just slightly too underpowered 
[00:47:49 CET] <Michael92> Ye that is correct, I am using the old one.. It install but when I try to use it I get [buffer @ 0x16ec1c0] Invalid pixel format string '-1'
[01:16:44 CET] <cone-595> ffmpeg 03Martin Storsjö 07master:58a840e21577: Replace a few leftover instances of enum PixelFormat with enum AVPixelFormat
[01:16:45 CET] <cone-595> ffmpeg 03Michael Niedermayer 07master:4fae55632236: Merge commit '58a840e21577a2168843487a98cb2cea44b5a94a'
[01:35:31 CET] <cone-595> ffmpeg 03Michael Niedermayer 07master:0f16dfda50cb: Replace PixelFormats which sneaked in over time or where forgotten by AVPixelFormats
[08:44:43 CET] <_3by8> Can someone in here please illuminate? If you were developing a website that sold videos but gave the customer the option of selecting file type and resolution, etc, would you rather store a copy of each file format locally or have the system transcode it on the fly with FFMPEG? I'm leaning towards local copies but please, illuminate me!
[09:11:43 CET] <av500> I would question a website that tries to sell videos
[09:19:22 CET] <_3by8> No insight as to performance of transcoding a video that is being downloaded at the same time?
[09:22:08 CET] <rcombs> _3by8: it really depends on your requirements, but as a general rule, disk space is cheaper than CPU time
[09:23:18 CET] <_3by8> rcombs, that was my thought also.
[09:24:06 CET] <av500> depends on how many videos you have
[09:24:15 CET] <rcombs> you also have to think about bandwidth, and if you're transcoding in realtime you're almost certainly not getting the optimal compression ratio for your quality target
[09:24:16 CET] <av500> vs how many different formats will be asked for
[09:24:28 CET] <rcombs> av500: and how many users you have, and what you're paying for everything
[09:24:43 CET] <av500> and and and ... :)
[09:24:46 CET] <rcombs> yup
[09:25:20 CET] <av500> _3by8: show us the pdf of your business plan and we can tell you more :)
[09:25:24 CET] <_3by8> haha
[10:02:06 CET] <ubitux> yuv420p, odd height: do we have an additional initialized luma height added at the end or not?
[10:08:13 CET] <nevcairiel> EINVALIDDATA is the correct answer to yuv420p odd height
[10:26:19 CET] <wm4> nevcairiel: the jpg decoder outputs it
[10:26:32 CET] <wm4> and cropping can produce it too
[10:26:40 CET] <nevcairiel> its still an invalid format
[10:26:48 CET] <wm4> ubitux: yes, and I even rely on it
[10:26:49 CET] <nevcairiel> 420 is not allowed to have an odd luma height
[10:27:07 CET] <nevcairiel> because half chroma pixels dont exist =p
[10:27:13 CET] <wm4> nevcairiel: unfortunately this clashes with reality
[10:27:27 CET] <wm4> and you treat it as if the dimensions were rounded up, but then cropped
[10:27:29 CET] <nevcairiel> also, why would you need an extra luma line? wouldnt you just need a rounded-up number of chroma lines?
[10:28:27 CET] <ubitux> wm4: you know if it's a dup of the last line or a black line?
[10:28:34 CET] <nevcairiel> i can do you one better even, odd height interlaced yuv420!
[10:28:37 CET] <ubitux> (yeah sorry too lazy to check)
[10:28:45 CET] <nevcairiel> its usually a dupe
[10:29:07 CET] <wm4> ubitux: that's a good question
[10:29:19 CET] <nevcairiel> might depend on codec
[10:32:40 CET] <ubitux> might it be uninitialized?
[10:33:25 CET] <ubitux> i wonder about odd columns too
[10:33:45 CET] <ubitux> we should really have more tests with nasty dimensions
[12:31:39 CET] <cone-179> ffmpeg 03Clément BSsch 07master:304fdfe9f3a3: lavfi: add showwavespic filter
[12:44:17 CET] <cone-179> ffmpeg 03Michael Niedermayer 07master:67e156222859: avfilter/vf_histogram: Change enum to int, which is accessed via AVOption as int
[12:44:18 CET] <cone-179> ffmpeg 03Michael Niedermayer 07master:ee17295d10aa: avfilter/vf_il: Change enums to int, which are accessed via AVOption as int
[12:44:19 CET] <cone-179> ffmpeg 03Michael Niedermayer 07master:fbb9ef5b1727: avfilter/vf_lut3d: Change enum to int, which is accessed via AVOption as int
[13:16:18 CET] <poste9> is it ok to keep pulling from the git source.ffmpeg ?
[13:16:36 CET] <poste9> Im getting this annoying error and cant fix it...libavdevice.a(xcbgrab.o): undefined reference to symbol 'xcb_setup_pixmap_formats_length'
[13:40:34 CET] <michaelni> poste9, how can this be reproduced ?
[13:41:18 CET] <michaelni> ubitux, is it somewhere documented how to run coverage on ffmpeg locally ?
[13:46:56 CET] <wm4> anyone knows what this means? "mjpeg: Unhandled pixel format 0x32111100 bits:8"
[13:50:03 CET] <wm4> ah, apparently 3:1:1 subsampling, whatever that is
[13:51:21 CET] <ubitux> michaelni: --toolchain=gcov
[13:51:55 CET] <michaelni> wm4, please open a ticket
[13:52:00 CET] <michaelni> ubitux, thx
[13:53:55 CET] <ubitux> michaelni: http://lucy.pkh.me/fate-configs/
[13:54:04 CET] <ubitux> and see coverage.cfg
[13:54:38 CET] <michaelni> thx
[13:56:07 CET] <ubitux> michaelni: ah, and "make lcov"
[13:56:30 CET] <ubitux> (after running fate or whatever test you want to test coverage)
[14:15:10 CET] <wm4> michaelni: convert image.png -sampling-factor 3:1:1 out.jpg
[14:15:17 CET] <wm4> michaelni: produces a sample file
[14:16:01 CET] <michaelni> wm4, thx
[15:30:27 CET] <cone-179> ffmpeg 03Derek Buitenhuis 07master:414d6547f331: mov: Add option to keep exact packet sequence after seeking
[16:11:27 CET] <kierank> maybe I should just bite the bullet and write sub8x8_dct_mpeg2
[16:55:08 CET] <Daemon404> i wasnt too "harsh" in my student review was i?
[16:57:01 CET] <av500> one can never be to harsh
[16:57:52 CET] <phh> av500: psss, broken avi
[17:00:03 CET] <kierank> Daemon404: oh wow it was a copy and paste?
[17:00:05 CET] <kierank> ok
[17:00:07 CET] <kierank> my view changes
[17:00:50 CET] <Daemon404> kierank, im not sure if it was
[17:00:57 CET] <Daemon404> or he added the comment randomly
[17:01:26 CET] <kierank> openexr is 3 clause i think, no?
[17:03:13 CET] <Daemon404> IlmImf/ImfB44Compressor.cpp:unpack14 (const unsigned char b[14], unsigned short s[16])
[17:03:16 CET] <Daemon404> yep copypasted
[17:03:39 CET] <Daemon404> kierank, i would fail the student for copypasting
[17:04:57 CET] <kierank> yeah
[17:06:02 CET] <wm4> would be reasonable
[17:06:16 CET] <wm4> + * OpenEXR decoder
[17:06:16 CET] <wm4> + * Digital Ltd. LLC
[17:06:16 CET] <wm4> + * All rights reserved.
[17:06:26 CET] <wm4> the original copyright is preserved though?
[17:06:46 CET] <wm4> so it's not outright evil, just not enough for qualification
[17:07:26 CET] <Daemon404> wm4, its not
[17:07:35 CET] <Daemon404> that is a significantly different legal meaning than teh 3-clause bsd
[17:07:42 CET] <Daemon404> what he put in there basically means "you cant use it"
[17:07:53 CET] <Daemon404> also it's not "Digital Ltd. LLC"
[17:07:55 CET] <Daemon404> it's ILM.
[17:08:23 CET] <wm4> ah
[17:08:58 CET] <Daemon404> that certainly explaisn all the shorts and unsigned chars and longs
[17:09:01 CET] <Daemon404> mixed with proper stdint
[17:10:16 CET] <Compn> good job for spotting copy and paste Daemon404
[17:10:25 CET] <Daemon404> kierank did
[17:11:49 CET] <Compn> good job on kierank then :)
[17:12:46 CET] <Compn> as for not passing a qualification... if they plug in code from another source and it works, while also following ffmpeg code rules, i think its ok
[17:12:57 CET] <Daemon404> i do not
[17:12:58 CET] <Compn> but it might not be a qual task , just a quick task...
[17:13:07 CET] <Daemon404> they are being paid, and it is supposed to be for learning.
[17:13:09 CET] <Compn> a qual task needs to be a larger thing.
[17:13:11 CET] <Compn> right
[17:13:15 CET] <Daemon404> it goes against the entire vision of gsoc
[17:13:33 CET] <Compn> learning to copy paste and save time coding is a skill no? :PPPP
[17:13:46 CET] <Daemon404> no it teaches them to be a shit programmer
[17:13:47 CET] <Compn> not a gsoc skill maybe
[17:13:48 CET] <Compn> ahah
[17:14:00 CET] <wm4> fortunately optimizing libpostproc is not against the spirit of gsoc
[17:14:37 CET] <kierank> it should be
[17:22:31 CET] <Compn> wm4 : going to port your synth wrapper to ffmpeg soon? :)
[17:22:45 CET] <Compn> or post patch etc
[17:22:52 CET] <Daemon404> why would he
[17:24:03 CET] <Compn> well if there was a newer* better* amazing* lib in ffmpeg for filtering, maybe libpostproc would finally be ignored / deprecated etc
[17:24:17 CET] <kierank> it won't
[17:24:33 CET] <kierank> unless every single niche feature was included in this new library
[17:24:54 CET] <Daemon404> is it even counted as niche if 0 people use it
[17:24:57 CET] <Daemon404> literally 0
[17:25:20 CET] <Compn> sure theres some person out there still using it. like lowres :D
[17:25:25 CET] <Compn> for commercial cutting :D
[17:28:39 CET] <wm4> Daemon404: that's wrong... many mplayer users have it in their config for no reason
[17:28:51 CET] <wm4> and play HD material with it
[17:28:57 CET] <wm4> the world is a terrible place
[17:29:24 CET] <Daemon404> like qscale?
[17:29:26 CET] <Daemon404> lol
[17:30:59 CET] <Compn> uspp=6! ehe
[17:31:36 CET] <Compn> wm4 : you should just make ppultimate and then charge your users $10 to use it
[17:31:46 CET] <Compn> make money off the terrible.
[17:32:00 CET] <Compn> but thats me, evil.
[17:37:55 CET] <Compn> ehe
[17:38:01 CET] <Compn> do we have this kind of closed caption?
[17:38:02 CET] <Compn> http://ht.cdn.turner.com/cnn/big/studentnews/2015/03/10/orig-sn-0311.cnn.scc
[17:38:06 CET] <Compn> seems new sample...
[17:40:49 CET] <kierank> won't be supported easily in ffmpeg
[17:40:53 CET] <kierank> since it syncs via timecode
[17:42:42 CET] Action: Daemon404 wrote support for those before
[17:42:45 CET] <Daemon404> hate that format
[17:44:02 CET] <Compn> sample saved here for future > http://samples.ffmpeg.org/sub/subcc/orig-sn-0311.cnn.scc
[17:44:11 CET] <nevcairiel> looks  like CC binary data in hex encoding
[17:44:11 CET] Action: Daemon404 has tons
[17:44:34 CET] <nevcairiel> with the occasional timestamp
[17:45:28 CET] <Compn> its not cea 608 708 ? :P
[17:46:02 CET] <Compn> Daemon404 : any other formats the sample repo is missing ? :P
[17:46:58 CET] <Compn> how many cc and subtitle formats are there :\
[17:47:04 CET] <nevcairiel> tons
[17:47:21 CET] <Compn> ughh
[17:47:42 CET] <Compn> collected a lot over the years for the sample repo
[17:52:33 CET] <kierank> it's cc data with timecode
[19:15:48 CET] <cone-179> ffmpeg 03James Cowgill 07master:f8323744a078: mips/float_dsp: fix vector_fmul_window_mips on mips64
[20:05:18 CET] <llllll> Hi there, 
[20:05:52 CET] <cone-179> ffmpeg 03Micah Galizia 07master:c59654d67d1a: avformat/http: replace cookies with updated values instead of appending forever
[20:18:42 CET] <llllll> Can anyone quickly explain me the difference between the LMS algorithm and the LMS predictive filter?
[20:18:45 CET] <llllll> pls
[20:21:57 CET] <michaelni> llllll, if this is about some codec, then the specification should explain what each is doing
[20:23:10 CET] <iive> what is LMS?
[20:23:57 CET] <llllll> Least mean squares
[20:24:08 CET] <llllll> and yea I am reading through it. 
[20:35:22 CET] <andrewrk> http://stackoverflow.com/questions/29131173/how-to-encode-24-bit-audio-with-libav-ffmpeg
[21:25:02 CET] <cone-179> ffmpeg 03Derek Buitenhuis 07master:8692d74b7364: mov: Add option to keep exact packet sequence after seeking
[21:25:03 CET] <cone-179> ffmpeg 03Michael Niedermayer 07master:b3818c47d8ba: Merge commit '8692d74b7364b405d7939c0ed347e8a2815193a7'
[21:39:05 CET] <cone-179> ffmpeg 03Carl Eugen Hoyos 07master:7f1ea38868e9: lavc/dts: Do not set bitrate for DTS-HD Master and High Resolution.
[21:39:06 CET] <cone-179> ffmpeg 03Carl Eugen Hoyos 07master:7a5356c7281d: lavf/mkv: Ignore ff_isom_write_hvcc() return value as the mov muxer does.
[21:39:07 CET] <cone-179> ffmpeg 03Michael Niedermayer 07master:ee648903f5e6: Merge remote-tracking branch 'cehoyos/master'
[23:39:58 CET] <cone-179> ffmpeg 03Michael Niedermayer 07master:e15455891bc6: avcodec/mjpegdec: Change upscale_* to an array instead of a bitmask
[23:39:59 CET] <cone-179> ffmpeg 03Michael Niedermayer 07master:b1fbe29e51c4: avcodec/mjpegdec: Support 31111100 sampling
[00:00:00 CET] --- Thu Mar 19 2015