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

[burek]

[00:54] <freezway> so I'm working on a music sorting program using libavformat and need to use it to read the metadata. The problem is some (poorly formed) files I have the metadata in the wrong spots. For example while a good file has the metadata inside input #0 a bad file might have it under Duration inside input#0 (as far as I can tell from ffprobe). I am currently using the metadata found under AVFormatContext->metadata
[00:55] <freezway> is there a better way to do this where it'll find the metadata no matter what?
[00:59] <freezway> oh whoops, sorry didn't read the /topic
[02:53] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:d0004a1959ec: avcodec/kgv1dec: fix memleak, reintroduce lost decode_flush() call
[04:31] <BBB> pengvado: oh wow... so... do you recommend we take this up with the yasm maintained and ask for a new release, or you think we should apply your workaround until yasm is fixed (or both), or ... I'm ok with anything really
[04:34] <BBB> I guess local workaround is fastest
[05:22] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:3ca7085ae2f7: avcodec: make "bitrate tolerance too small for bitrate" error more verbose
[06:05] <cone-6> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.10.11': unknown revision or path not in the working tree.
[06:05] <cone-6> Use '--' to separate paths from revisions
[06:05] <cone-6> refs/tags/n0.10.11:HEAD: avcodec: make "bitrate tolerance too small for bitrate" error more verbose
[08:09] <ubitux> is there any x86_64 cpu without ssse3?
[08:10] <nevcairiel> yes
[08:11] <ubitux> ok
[08:11] <ubitux> (can you name one?)
[08:11] <nevcairiel> especially AMD has been rather late with supporting SSSE3
[08:11] <ubitux> mmh
[08:11] <nevcairiel> so first gen athlon64 for sure
[08:11] <nevcairiel> even first intel 64 dont have it
[08:11] <nevcairiel> ie. Pentium D
[08:11] <ubitux> mmh okay
[08:12] <ubitux> thanks
[08:12] <nevcairiel> the first x86_64 cpu was released 2003, the first with SSSE3 in 2006
[08:12] <nevcairiel> you do the math
[08:12] <nevcairiel> :D
[09:59] <plepere> hello
[12:57] <kriegerod> the build is broken, do you know?
[12:57] <kriegerod> libavcodec/vc1dec.c:5185: undefined reference to `ff_intrax8_decode_picture'
[12:57] <kriegerod> etc.
[12:57] <Rodeo> kriegerod: FATE seems greenish http://fate.ffmpeg.org/?dsort=date
[12:58] <BBB> kriegerod: make clean; configure; make
[12:59] <kriegerod> hm okay, i'll reconfigure
[12:59] <BBB> oh really the lpf is 99% sse2
[12:59] <BBB> that's pretty good
[13:00] <kriegerod> it just didn't warn me that configure has changed as it happens sometimes
[13:01] <BBB> it's also quite easy to make a sse2 mc, if anyone is interested (see vp8 for examples)
[13:01] <kriegerod> is it possible to somehow detect the need for reconfigure at just `make`?
[13:01] Action: BBB no build expert
[13:10] <J_Darnley> Can someone help me work out why I get this error while running fate: http://pastebin.com/iuj9WAd1
[13:15] <BBB> J_Darnley: make fate-rsync
[13:16] <BBB> (you're missing a sample)
[13:16] <J_Darnley> I am not
[13:16] <J_Darnley> I did that less than 12 hrs ago
[13:19] <J_Darnley> $ ls -l /cygdrive/z/fate-samples/bmp/test1.bmp
[13:19] <J_Darnley> -rwx------ 1 ???????? ???????? 1086 Mar 31  2012 /cygdrive/z/fate-samples/bmp/test1.bmp
[13:21] <nevcairiel> are you sure --enable-protocol='file,pipe,md5' works? Not sure i've seen it used before..
[13:34] <BBB> J_Darnley: other alternative is that the command is crashing, try "make V=1 fate-bmp-1bit" to see what ffmpeg command it's running and run that yourself manually
[13:38] <Daemon404> i dont think anyone regularily test or runs ffmpeg on cygwin at all
[14:00] <J_Darnley> Daemon404: There is a cygwin machine runnig fate which successfully ran 15 hours ago: http://fate.ffmpeg.org/history.cgi?slot=x86_64-win7-cygwin-gcc-4.5.3
[14:03] <Daemon404> nifty.
[14:03] <J_Darnley> nevcairiel: that is the recomended way to do it.
[14:07] <ubitux> BBB: any objection to applying the lpf sse2 patch
[14:07] <ubitux> ?
[14:07] <BBB> not at all
[14:08] <ubitux> ok
[14:08] <ubitux> BBB: btw, i can't do the 4_16 and 8_16 easily
[14:08] <ubitux> it's not the good way around :p
[14:08] <BBB> ?
[14:08] <BBB> huh?
[14:08] <BBB> what does that mean
[14:08] <ubitux> it's not 16 wide
[14:08] <ubitux> it's 16 height
[14:08] <BBB> ?
[14:09] <BBB> it does 16 pixels at once, with a filter of size 4 or 8
[14:09] <ubitux> i mean it's not just disabling filter14() and filter6()
[14:09] <BBB> it is
[14:09] <BBB> look at the c implementation
[14:09] <BBB> in c it's called 44_16 and 88_16
[14:09] <ubitux> maybe i misunderstood
[14:09] <ubitux> aaah
[14:09] <ubitux> ok
[14:10] <ubitux> i can do those then :)
[14:10] <BBB> and 84_16 and 48_16 are the mix functions which are essentially 88_16 with a fixed zero-mask for the 4-half of filter6
[14:10] <BBB> yeah sorry the c is a little tricky
[14:11] <BBB> the c is basically written that way to make simd easier, but maybe that wasn't obvious because it's hidden in macros :-p
[14:11] <ubitux> i was thinking about 8_16 and 4_16
[14:11] <ubitux> no 44_16 and 88_16, i guess
[14:11] <ubitux> not*
[14:12] <BBB> I bet you were looking at lf_8_fns(16)
[14:12] <BBB> which is 16_8
[14:12] <BBB> and then 16_16 just calls 16_8 twice (in c)
[14:12] <BBB> you wrote 16_16 in straight simd
[14:13] <BBB> that's lf_16_fn(h, stride)
[14:13] <BBB> and then the interesting parts for 44_16 and 88_16 are lf_mix_fns(4, 4)
[14:13] <BBB> and the other 3
[14:13] <ubitux> yeah sorry i was confused yesterday night
[14:13] <ubitux> :))
[14:15] <BBB> like I said, the c code is a little confusing
[14:15] <BBB> but I do believe it makes simd faster
[14:17] <cone-6> ffmpeg.git 03James Almer 07master:d2a7314f1e0d: vp9/x86: add ff_vp9_loop_filter_[vh]_16_16_sse2().
[14:38] <cone-6> ffmpeg.git 03Martin Storsjö 07master:03f2de5856ec: aviocat: Check the argv array length before reading element i+1
[14:38] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:9f3a555b84ba: Merge commit '03f2de5856ec8571fcf5f4cf6dccc713294af545'
[14:44] <cone-6> ffmpeg.git 03Martin Storsjö 07master:87acd33c092a: aviocat: Add support for specifying the input duration
[14:44] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:c8b99f8ad058: Merge commit '87acd33c092ab9e7d73686627e9105d99c1e4928'
[15:05] <cone-6> ffmpeg.git 03Luca Barbato 07master:ff23c4e4935e: doxy: Add AVFrame to the structured modules
[15:05] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:68ebf70f665b: Merge commit 'ff23c4e4935e96e62d8ff2212a1955a43add88e1'
[15:09] <J_Darnley> Well my problem is that ffmpeg seems to think it is supposed to find an image sequence
[15:17] <cone-6> ffmpeg.git 03Luca Barbato 07master:045654f422e7: doxy: Document better the available AVFrame flags
[15:17] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:045d80076a67: Merge commit '045654f422e74be8ed09a0819d39051d67633a09'
[15:20] <J_Darnley> There's no option to tell ffmpeg to not look for a pattern!?
[15:29] <cone-6> ffmpeg.git 03Anton Khirnov 07master:f9cc6883a4e5: mp3enc: add an option for disabling the Xing frame.
[15:30] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:5049b6a1fe52: Merge commit 'f9cc6883a4e5cf72cbfa21d17e1908a2a432f6bd'
[15:45] <J_Darnley> git add -i
[15:45] Action: J_Darnley swears
[15:49] <ubitux> any reason yasm is prefered over nasm btw?
[15:50] <JEEB> http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=a7fd9f5da062de323ae89f9a71ede03bfd6ddb6a
[15:50] <JEEB> this was the original reason
[15:51] <ubitux> ok
[15:52] <ubitux> right now with the macro exhaustion bug, it takes 4.83s with nasm, and 39.46s with yasm
[15:53] <JEEB> anyways, it seems like nasm did get a nice amount of development at least commit-wise since, and yasm mostly died out after yasm-nextgen seems to have not become A Thing
[15:53] <JEEB> both should be reviewed IMHO
[15:53] <JEEB> not that I have much of an idea how to test them :P
[15:54] <cone-6> ffmpeg.git 03Anton Khirnov 07master:33018907bd07: mp3enc: allow omitting the id3v2 header with -id3v2_version 0
[15:54] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:58770db2ae67: Merge commit '33018907bd07b34e0e70d5ae12097265eb3734d7'
[16:17] <J_Darnley> Oh screw it!  I'll just use -k and hope I don't miss the changes I'm looking for.
[16:18] <cone-6> ffmpeg.git 03Anton Khirnov 07master:2ce8bca51f72: avconv: print a warning when falling back to default 25fps
[16:18] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:206c06d96f68: Merge commit '2ce8bca51f7264b47027f69d50dd8e49aa2fd683'
[16:33] <cone-6> ffmpeg.git 03Anton Khirnov 07master:5ef11b8dcc05: yuv4mpeg: set average frame rate
[16:33] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:6e2d3ba0eea1: Merge commit '5ef11b8dcc054b230deb9b20493255c14a80597d'
[16:42] <Compn> ubitux : yasm was more widely installed in distros i guess
[16:42] <Compn> i dont remember exactly...
[16:43] <nevcairiel> there used to be more issues with nasm over the last couple years that i've paid attention then with yasm
[16:43] <nevcairiel> but of course that could only be because every dev builds it for yasm
[16:43] <nevcairiel> so shrug
[16:43] <Compn> then we supported both because its always good to work on multiple tools...
[16:43] <Compn> like multiple compilers, intel, clang, gcc
[16:43] <Compn> a warning on one is an error on another
[16:43] <nevcairiel> both are still supported today
[16:43] <Compn> right
[16:44] <cone-6> ffmpeg.git 03Anton Khirnov 07master:104a97beaffa: buffersrc: handle non-refcounted frames in av_buffersrc_add_frame() correctly
[16:44] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:cd259cdaa947: Merge commit '104a97beaffa6348e6fd2c2d07d67c1402322bb3'
[16:48] <michaelni> ubitux, do you have time to review ' mpegts muxer and demuxer: correct DVB teletext processing' patch from Andriy Lysnevych on ML ?
[16:48] <ubitux> i'm not familiar with that area
[16:49] <ubitux> ask marton maybe
[16:49] <ubitux> he worked on the teletext decoder
[16:57] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:c9db8694a836: avisynth: fix setting packet properties
[16:57] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:f1edf881ef83: Merge remote-tracking branch 'qatar/master'
[17:05] <michaelni> ubitux, ok, sent mail
[17:05] <ubitux> maybe kierank or reimar know too :p
[17:08] <michaelni> now if my time machine wasnt broken i could add them to CC ...
[17:08] <Compn> michaelni : i have a sample that previously (back in 2008) used INMC fourcc for mpeg4 asp  , but i got a sample the other day that has INMC but is h264...
[17:09] <michaelni> Compn, where can i find both these samples ?
[17:09] <Compn> i have the new one, but i dont seem to have the one from 2008
[17:10] <cone-6> ffmpeg.git 03Carl Eugen Hoyos 07master:ee3fc8aa864f: Fix libxvid crash on failing initialisation.
[17:10] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:68ed0b6cd111: Merge remote-tracking branch 'cehoyos/master'
[17:10] <Compn> i meant 'there is a codec that previously used inmc' :)
[17:11] <Compn> because i cant find the old sample now :)
[17:12] <Compn> my idea was to have a special decoder for unknown fourccs, and it tests the most common decoders, if it finds errors it skips to the next decoder.
[17:12] <nevcairiel> you mean like probing works today? :d
[17:12] <Compn> sure :)
[17:12] <Compn> can we do codec probing ? :)
[17:12] <Compn> on unknown fourccs ? :))
[17:14] <nevcairiel> probing is only supported for a couple codecs, but it would try to probe for those if its unknown
[17:32] <Compn> i wish i could find the old sample
[17:46] <Compn> michaelni : idea for noise reduction video filter based on photoshop 'average composite' , http://spreadys.wordpress.com/2013/10/14/a-few-helpful-hints/
[17:46] <Compn> wonder how well it works vs our filters
[17:50] <{V}> Compn, maybe you can create a sample http://spreadys.wordpress.com/2013/07/27/inmc-codec-update/
[17:50] <{V}> (of the INMC thing)
[17:53] <{V}> oh same blog. oops :)
[17:53] <Daemon404> that blog is full of retarded stuff...
[17:55] <wm4> "I have now placed this .dll into my SMplayer Pack and configured the codecs.conf accordingly."
[17:55] <wm4> :(
[17:57] <Compn> why are you sad wm4 ?
[17:57] <wm4> that someone uses the horrible mplayer dshow interop code
[17:57] <wm4> in 2014
[17:58] <Compn> its not like codec manufacturers provide source and c-compiled libs ;p
[17:58] <wm4> they could just use a real dshow player
[17:58] <Compn> {V} : pretty sure its decode-only codec but i'll take a look at it
[17:59] <{V}> oh
[17:59] <Compn> wm4 : he explains elsewhere on the blog why he dislikes codec installers
[17:59] <Compn> common complaint is that they mess up peoples computers easily
[18:00] <Compn> take over decoding , break decoding, add watermarks, etc
[18:00] <Compn> upsidedown decoding :D
[18:00] <Compn> of all divx video...
[18:02] <Compn> {V} : Loaded DLL driver MultiCodec.dll at 10000000 . Failed to open the encoder.
[18:02] <Daemon404> [16:57] <+wm4> that someone uses the horrible mplayer dshow interop code
[18:02] <Daemon404> um
[18:02] <Daemon404> its vfw
[18:02] <Daemon404> not dshow
[18:02] <Daemon404> get your shit right bro
[18:02] <wm4> k
[18:02] <nevcairiel> fact remains, its shit =P
[18:03] Action: Compn lobbies for dll loader in ffmpeg
[18:03] <Compn> bwahaha
[18:03] <Daemon404> the guy seems to be pretty clueless from rading his blog
[18:03] <wm4> mplayer has both
[18:03] <Daemon404> he uses tools that were cool in 2001
[18:03] <Compn> Daemon404 : shh, his vb skillz are leet
[18:03] <iive> The text says this is "Multi-standard video codec". so most probably it should be treated as container inside container.
[18:03] <Daemon404> Compn, i like is 'video concatenator'
[18:03] <Daemon404> his*
[18:04] <Compn> he keeps putting h264 in avi. :\
[18:04] <Daemon404> [17:03] <@Daemon404> the guy seems to be pretty clueless from rading his blog
[18:04] <nevcairiel> so many people put all kinds of shit in avi
[18:04] <Daemon404> whats scary is that these are the people who can help or fuck up putting others in prison.
[18:04] <Compn> yep
[18:05] <Compn> comes down to 1s and 0s
[18:05] <Compn> ... and mplayer's binary loader
[18:05] <Compn> (dont live in america if you can avoid it)
[18:06] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:ee27b113069e: avformat/riff: fix demuxing of h264 INMC
[18:06] <JEEB> h.264 in avi reminds me of this guy called timecop :P
[18:07] Action: Daemon404 lives in america lite
[18:07] <Daemon404> you can go to jail for tweeting here!
[18:07] <Daemon404> :D
[18:08] <Compn> thats awesome
[18:08] <Compn> at least you still have jail
[18:08] <Compn> we have secret jail
[18:08] <Daemon404> >implying uk doesnt
[18:09] <Compn> you got a queen and a princess now or something
[21:30] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:f1caaa1c6131: dnxhdenc: fix mb_rc size
[21:30] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:19df5dcb4734: avcodec/dnxhdenc: check that qmax is within the supported range
[21:30] <cone-6> ffmpeg.git 03João Bernardo 07master:447d71b89213: avfilter/vf_elbg: Fixed seed range of elbg filter
[22:12] <wm4> michaelni: so, can Ben Boeckel's ogg tag patches be merged?
[22:40] <michaelni> wm4, one of the pactches has a comment by ubitux
[22:40] <michaelni> the others have issues too i think, but let me do a proper review
[22:40] <ubitux> https://github.com/DarkShikari/x264-devel/commit/8a27cd68d3d6137b8a38ccef1770a1b3ef78bdfb
[22:40] <ubitux> should we pick that?
[22:42] <nevcairiel> we usually backport x86inc changes to keep as close as possible to upstream
[22:55] <michaelni> nevcairiel &, ubitux yes
[23:09] <michaelni> wm4, ogg patches review done (or at least i think all patches got a review now)
[23:10] <wm4> michaelni: thanks
[23:16] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:ed7f1a5c2076: avformat/metadata: allow ff_metadata_conv() to be called with NULL saftely
[00:00] --- Sat Jan 18 2014