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

Thu Jul 23 02:05:02 CEST 2015

[01:31:06 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:385eb066ce8c: avformat/asfdec_f: Increase the amount of information provided in cases of errors
[01:31:07 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:5d79a0731675: avformat/asfdec_f: Do not print errors if packets do not start with ECC
[01:31:08 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:0671dc5c5327: avformat/asfdec_f: Improve packet resync heuristic
[05:18:39 CEST] <cone-051> ffmpeg 03Niklesh 07master:93e80a343bfb: movtextenc.c: Reorganize the code for easier maintenance
[05:18:39 CEST] <cone-051> ffmpeg 03Niklesh 07master:d373b508b540: movtextenc.c: Add support for text highlighting
[08:58:42 CEST] <dericed> IETF session on FFV1/MKV about to start. jabber xmpp:dispatch at jabber.ietf.org?join audio http://congresshall3.conf.meetecho.com:8000/congresshall3.opus meetecho https://congresshall3.conf.meetecho.com/meetecho/login.jsp?ietf=dispatch
[11:47:20 CEST] <cone-500> ffmpeg 03Carl Eugen Hoyos 07master:35b33f1a195c: lavf/mxfdec: Set codec_tag AVup for Avid 1:1 input.
[11:47:20 CEST] <cone-500> ffmpeg 03Carl Eugen Hoyos 07master:6b2bb3d231f8: Cosmetics: Reindent after last commit.
[12:20:21 CEST] <Compn> dericed : cool. that was 3am for me ;)
[14:20:26 CEST] <iive> michaelni: are you around?
[14:21:18 CEST] <durandal_1707> michaelni: does this crash for you: ffmpeg -f lavfi=color=s=2x2:d=4000 -vf reverse -f null -
[14:21:43 CEST] <D404|Ghetto> i wouldnt be surprised if it did
[14:23:06 CEST] <michaelni> "./ffmpeg -f lavfi -i color=s=2x2:d=4000 -vf reverse -f null -" does not crash here
[14:23:44 CEST] <durandal_1707> ahh then my system realloc is borked
[14:24:14 CEST] <iive> Raz-: michaelni  is around, you can talk with him in query or here. however you like.
[14:26:44 CEST] <D404|Ghetto> durandal_1707: that would seem pretty unlikely
[14:26:53 CEST] <D404|Ghetto> what sort of crash is it
[14:28:01 CEST] <durandal_1707> Segmentation fault, and just when are few frames left to flush
[14:30:44 CEST] <D404|Ghetto> durandal_1707: hmm
[14:30:48 CEST] <D404|Ghetto> it could be a bug maybe?
[14:30:55 CEST] <D404|Ghetto> iirc i tested and valgrind was clean
[14:31:07 CEST] <D404|Ghetto> if youre on bsd it may be pickier
[15:00:08 CEST] <cone-469> ffmpeg 03hSÇ 07master:3e35f8efa18d: avcodec: loongson optimize pixblockdsp with mmi
[15:00:09 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:9837d3b06844: avformat/asfdec_f: Parse ECC byte according to spec
[15:21:20 CEST] <AstralStorm> hello, I'm having trouble with ffmpeg finding muxer for m4a... after digging I've ended up at av_match_name
[15:21:24 CEST] <AstralStorm> http://ffmpeg.org/doxygen/trunk/avstring_8c_source.html#l00342
[15:21:48 CEST] <AstralStorm> ipod muxer says extensions = "m4v,m4a"
[15:22:49 CEST] <dericed> Compn: was 3am for me too, zzzzzz
[15:23:15 CEST] <AstralStorm> line 352 there is fishy, shouldn't it be FFMIN?
[15:24:25 CEST] <AstralStorm> not even that, this len seems quite wrong
[15:30:16 CEST] <AstralStorm> nah, it is correct
[15:30:59 CEST] <AstralStorm> other than tossing namelen for the non-first entry
[15:31:52 CEST] <AstralStorm> nah, the loop will exit early then, it's ok
[15:32:51 CEST] <AstralStorm> wait a second, what is av_match_name supposed to do? it's not av_match_extension
[15:33:00 CEST] <AstralStorm> it compares the whole name to the extension
[15:33:55 CEST] <AstralStorm> the bug is in av_guess_format
[15:34:18 CEST] <AstralStorm> no, again, av_match_ext is used
[15:34:57 CEST] <nevcairiel> av_match_ext is a tiny wrapper around av_match_name that strips the extension of the filename and then compares it to the extension list with av_match_name
[15:35:00 CEST] <nevcairiel> codel ooks fine
[15:35:26 CEST] <AstralStorm> indeed, the path contains more dots
[15:35:42 CEST] <AstralStorm> I wouldn't suspect strrchr to be wrong
[15:36:39 CEST] <AstralStorm> but, it's avio_open failing with protocol not found
[15:36:46 CEST] <AstralStorm> av_register_all is certainly called
[15:37:09 CEST] <nevcairiel> maybe your build forgot to include the file protocol?
[15:37:15 CEST] <nevcairiel> that happened to me once
[15:37:17 CEST] <AstralStorm> no, it's definitely there
[15:37:25 CEST] <AstralStorm> and the encoder worked for writing raw AAC bitstreams
[15:37:30 CEST] <AstralStorm> now I'm trying to get m4a
[15:37:37 CEST] <AstralStorm> that should pick ipod muxer
[15:38:47 CEST] <AstralStorm> hmm, is the list of protocols in configure comma separated or space separated or?
[15:39:04 CEST] <nevcairiel> if you use --enable-protocols= then its comma separated
[15:39:11 CEST] <nevcairiel> configure will give you an output of things enabled
[15:39:13 CEST] <nevcairiel> so you can check
[15:39:31 CEST] <nevcairiel> check that your muxer, codec and  protocol are there
[15:39:52 CEST] <AstralStorm>     --enable-protocol=concat,data,file,subfile \
[15:40:08 CEST] <nevcairiel> that should probably work
[15:40:40 CEST] <nevcairiel> but better to double check
[15:41:25 CEST] <AstralStorm> how can I list the protocols?
[15:44:06 CEST] <AstralStorm> ah, I see, I need to iterate av_oformat_next
[15:56:25 CEST] <AstralStorm> interesting, now it worked? I potentially have a race condition somewhere vs av_register_all
[15:56:44 CEST] <AstralStorm> that said: av: Encoder did not produce proper pts, making some up. (aac native)
[15:57:04 CEST] <AstralStorm> I'll do it manually of course
[16:09:20 CEST] <wm4> AstralStorm: the register functions are not thread-safe
[16:09:24 CEST] <wm4> they also touch global state
[16:09:26 CEST] <wm4> have fun
[16:10:26 CEST] <AstralStorm> yup, noticed
[16:27:35 CEST] <Swinehorn> hey guys. I'm compiling ffmpeg with VS2013 (--toolchain=msvc), and I want add libfdk-aac. Unfortunately fdk-aac doesn't have VS solution, I compiled .lib file by MinGW but this lib file is not valid for linking with ffmpeg.
[16:27:36 CEST] <Swinehorn> can you please advice, how to make compatible fdk-aac .lib file ?
[16:28:12 CEST] <nevcairiel> you will need to build it with msvc somehow, building your own solution if they dont provide one
[16:28:19 CEST] <nevcairiel> mingw static libraries do not work with msvc builds
[16:28:32 CEST] <j-b> take the .dll generated by MinGW. Create the .lib from it.
[16:28:45 CEST] <cone-469> ffmpeg 03Tom Butterworth 07master:c7e6443441ed: Support the Hap chunked frame format
[16:29:01 CEST] <nevcairiel> i suppose that can work if you can accept a separate dll
[16:29:01 CEST] <Swinehorn> j-b, you're genius))
[16:29:15 CEST] <AstralStorm> weird, I get the "making some up" message when I set pts to 0
[16:29:28 CEST] <AstralStorm> essentially setting them to -1024 for first frame, 0 for second etc.
[16:30:32 CEST] <j-b> dumpbin /exports "BLA.dll" > "BLA.lib" in the Visual Studio Command Prompt
[16:31:25 CEST] <Swinehorn> I'll try thx very much)
[16:32:24 CEST] <AstralStorm> mpv now says the pts are fine, first frame is -0.021s (48000 ksps)
[16:38:15 CEST] <cone-469> ffmpeg 03Luca Barbato 07master:3ae0e721c7b6: checkasm: Always link statically
[16:38:16 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:c1692439e081: Merge commit '3ae0e721c7b6e0483801b9039b3d140e3b68b7f5'
[16:41:49 CEST] <AstralStorm> ah, I see, I should also set dts, seems ffmpeg actually checks this
[16:46:07 CEST] <cone-469> ffmpeg 03Janne Grunau 07master:e605bf3b590d: checkasm: remove empty array initializer list in h264pred test
[16:46:08 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:e1b5a2e46ef0: Merge commit 'e605bf3b590d295f215fcc9fd58eb11be55b68cb'
[16:46:35 CEST] <durandal_1707> D404|Ghetto: checking pts instead of frames in filter frame fixes it
[16:53:21 CEST] <cone-469> ffmpeg 03Anton Khirnov 07master:ecee1148af49: qsvenc_hevc: use the correct HW plugin UID
[16:53:22 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:fbdbe7a5d262: Merge commit 'ecee1148af4989e1f9e16f0cdc9f98ad2045538c'
[17:06:21 CEST] <cone-469> ffmpeg 03Alexandra Hájková 07master:5655236a6720: asfdec: factor out seeking to the Data Object outside while
[17:06:22 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:fce350be0e75: Merge commit '5655236a67203d923755f285584c6e68abe7e33f'
[17:12:37 CEST] <Swinehorn> j-b, ffmpeg with fdk-aac successfully compiled and works, great!!)
[17:13:19 CEST] <cone-469> ffmpeg 03Alexandra Hájková 07master:93f16f338f9e: asfdec: close the demuxer properly when read_header is failing
[17:13:20 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:fa7defc89a7b: Merge commit '93f16f338f9e8aba0c006752eb3afc3fe6e137fd'
[17:21:59 CEST] <durandal_1707> D404|Ghetto: sent patches
[17:22:43 CEST] <cone-469> ffmpeg 03Alexandra Hájková 07master:2a187a074a7f: asfdec: avoid crash in the case when chunk_len is 0 or pkt_len is 0
[17:22:44 CEST] <cone-469> ffmpeg 03Vittorio Giovara 07master:ea4d46e72945: dds: Fix enum declaration
[17:22:45 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:6b9be608ce92: Merge commit '2a187a074a7f5ad9f01f72ac9715ddfcb2dbb8ec'
[17:22:46 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:eaf15bba03b4: Merge commit 'ea4d46e72945cba37feb7aa154eb970732f513e4'
[17:23:59 CEST] <D404|Ghetto> durandal_1707: i dont get why that fixes it
[17:26:59 CEST] <nevcairiel> different sizes in those variables?
[17:28:44 CEST] Action: durandal_1707 laughs at libav diff filter
[17:30:08 CEST] <nevcairiel> i agree with D404|Ghetto, those two arrays are always allocated at the same time to the same size, it makes no sense for the patch to help
[17:31:14 CEST] <nevcairiel> unless fast realloc does something weird
[17:31:18 CEST] <nevcairiel> which it may
[17:31:22 CEST] <nevcairiel> its one of those magic functions
[17:31:29 CEST] <nevcairiel> .. so their size does desync
[17:31:47 CEST] <D404|Ghetto> i dont think thats possible
[17:32:14 CEST] <D404|Ghetto> hmm... oh right...
[17:32:40 CEST] <D404|Ghetto> [B[Bnope
[17:32:55 CEST] <D404|Ghetto> it's impl makes it clear they ought to be the same...
[17:33:13 CEST] <nevcairiel> why
[17:33:18 CEST] <D404|Ghetto> http://ffmpeg.org/doxygen/trunk/mem_8c_source.html#l00480
[17:33:51 CEST] <D404|Ghetto> size and min=size are a function of nothing but themselves
[17:34:07 CEST] <nevcairiel> plus integer division
[17:34:17 CEST] <D404|Ghetto> but theyre the same
[17:34:21 CEST] <nevcairiel> and on 32-bit the pointer is only 4 bytes
[17:34:33 CEST] <nevcairiel> so it could behave differently
[17:34:39 CEST] <D404|Ghetto> ah...
[17:34:48 CEST] <D404|Ghetto> how evil.
[17:35:24 CEST] <D404|Ghetto> i guess the real fix is to check both or track manually... 
[17:35:30 CEST] <D404|Ghetto> both of which make av_fast_realloc utterly useless
[17:35:33 CEST] <D404|Ghetto> compared to av_realloc
[17:35:33 CEST] <D404|Ghetto> :D
[17:39:46 CEST] <cone-469> ffmpeg 03Vittorio Giovara 07master:57214b2f7f9b: dds: Fix palette decoding
[17:39:47 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:d08d8b61aa9f: dds: Fix 32bpp bitmaps decoding
[17:39:48 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:05cf687d130a: Merge commit '57214b2f7f9b1ccfd61e232e8989b5ee850f169c'
[17:39:49 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:b68e445f9b34: Merge commit 'd08d8b61aa9f07d3ea993fe5392f7408c958d221'
[17:47:11 CEST] <Compn> iive : bulgarian hosting offer on the list now
[17:48:05 CEST] <iive> :)
[17:56:40 CEST] <cone-469> ffmpeg 03Paul B Mahol 07master:787d370e1424: avfilter: add deband filter
[18:00:05 CEST] <iive> i'm not involved with any of these firms, so you can be sure I won't take over ffmpeg :D
[18:00:35 CEST] <Raz-> :))
[18:07:39 CEST] <cone-469> ffmpeg 03Vittorio Giovara 07master:a16854892c3a: dds: Add a rgba fate test
[18:07:40 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:d231d2be7101: Merge commit 'a16854892c3af945d3ab0015699a0c9884f0a89a'
[18:17:24 CEST] <cone-469> ffmpeg 03Vittorio Giovara 07master:21c90d86d27c: mpegvideo: Add missing include
[18:17:25 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:1d7fa1ac8932: Merge commit '21c90d86d27c2143354c7d782050a779b0986eb1'
[18:52:07 CEST] <cone-469> ffmpeg 03Donny Yang 07master:a906e86a8dbd: apng: Fix decoding images with the PREVIOUS dispose op
[19:25:24 CEST] <AstralStorm> hmm, about this AAC, there's a nice icassp 2006 paper about multidimensional linear programming for quantization mode, long block and short block picking
[19:25:41 CEST] <AstralStorm> Multidimensional Optimization of MPEG-4 AAC Encoding; Claus Bauer, Matt Fellers, Grant Davidson; Dolby
[19:25:46 CEST] <AstralStorm> not sure about patents on this
[19:29:28 CEST] <JEEB> ffmpeg doesn't really care too much about patents, otherwise a lot of the stuff wouldn't be implemented
[19:29:50 CEST] <JEEB> like DTS or Dolby formats and friends
[19:31:40 CEST] <AstralStorm> I think they've posed the problem for CBR there, for some rate threshold
[19:32:20 CEST] <AstralStorm> for VBR the optimization would aim at some PSNR or perceptual entropy value... for ABR this algorithm does not work, as you need additional constraint
[19:32:44 CEST] <AstralStorm> that constraint is unfortunately nonlinear
[19:35:09 CEST] <AstralStorm> I mean, for VBR there's a nice equality constraint on PE or PSNR
[20:00:33 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:c40ecffd31d0: Replace AV_PKT_DATA_QUALITY_FACTOR by AV_PKT_DATA_QUALITY_STATS
[20:00:34 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:557e011bf167: avcodec/libxavs: Export pict_type in side data
[20:16:40 CEST] <atomnuker> If I give init_put_bits() a NULL buffer can I use the context to just measure how many bits it has pretended to write?
[20:17:59 CEST] <durandal_1707> nope that will crash IIRC
[20:33:20 CEST] <atomnuker> PutBits is used by a ton of encoders
[20:33:45 CEST] <atomnuker> Would it be a crime to put another field in the context to make the put_bits() only increment it and not actually write anything?
[20:41:45 CEST] <iive> can you do that without putting condition (if) in all the related functions?
[20:42:43 CEST] <atomnuker> yep
[20:42:55 CEST] <atomnuker> only in put_bits() and in put_bits_count()
[20:43:11 CEST] <kierank> lglinskih: hi
[20:43:13 CEST] <iive> but these are the expensive function....
[20:43:37 CEST] <atomnuker> it's just a single comparison, can it really be that bad?
[20:43:41 CEST] <iive> if()s are expensive, one wrong prediction and you have stall of 300 cycles.
[20:44:25 CEST] <nevcairiel> yeah those functions are over-optimized, overhead in them should be avoided
[20:44:42 CEST] <kierank> atomnuker: you could do it how x264 does it
[20:44:56 CEST] <kierank> it uses a macro to redefine the function
[20:45:06 CEST] <nevcairiel> i suppose that might work
[20:45:09 CEST] <atomnuker> yeah, that was the original plan
[20:55:04 CEST] <BBB> I think thats better/easier, yes
[20:56:08 CEST] <iive> i don't remember how they are written... do they have a check for remaining space?
[20:57:21 CEST] <iive> aka, one possible hack is to give them buffer with length zero, the check would always fail and prevent actual write to the buffer. The hack would be to increment the written amount.
[20:58:11 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:caba19a5becc: avcodec/dnxhdenc: Set pict type for AV_PKT_DATA_QUALITY_STATS correctly
[20:58:12 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:975257ffe650: avcodec/libx264: Export choosen pict_type
[21:11:28 CEST] <lglinskih> kierank: hi! I came back to work: I'm trying to test draw_horiz_band for other codecs. Now I'm playing with h263 test file.
[21:11:36 CEST] <kierank> ok
[21:11:44 CEST] <kierank> wm4 had some comments about seek test
[21:14:26 CEST] <wm4> lglinskih: you had this idea to decode the file completely in a first pass, and then trying again with seeking, and comparing the results to the first pass
[21:14:43 CEST] <wm4> lglinskih: that sounds like a very good way to get a useful test
[21:19:47 CEST] <lglinskih> wm4, kierank: ok!
[21:23:31 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:3d083f6ffd8c: avformat/dump: Also print pict_type in dump_sidedata() for AV_PKT_DATA_QUALITY_STATS
[21:23:32 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:5362df2ee383: avcodec: remove unused sd variables
[21:23:44 CEST] <wm4> lglinskih: another, more fuzzy test: check where a seek actually lands, and see whether the result is acceptable
[21:24:00 CEST] <wm4> if you seek to 5 seconds, and end up at 5 minutes, the result is obviously not so great
[21:25:51 CEST] <lglinskih> =) 
[21:26:46 CEST] <wm4> on the other hand, you can't expect seeks to be exact, of course, only within what's technically possible
[22:23:26 CEST] <cone-469> ffmpeg 03Jovan Zelincevic 07master:631496e057a2: avcodec: Table creation for AAC_fixed_decoder (PS-module)
[22:23:27 CEST] <cone-469> ffmpeg 03Djordje Pesut 07master:5fd81cf6f082: avcodec: Implementation of AAC_fixed_decoder (PS-module)
[22:23:28 CEST] <cone-469> ffmpeg 03Nedeljko Babic 07master:978a8540b6ce: tests: Add aac_fixed decoder test
[22:35:44 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:4845f6687d4f: fate: Make ffprobe tests depend on avdevice
[23:06:15 CEST] <BBB> wm4: frame-exact seeking is not so hard, in fact
[23:07:09 CEST] <wm4> but you can't do it in the demuxer
[23:08:36 CEST] <BBB> oh demuxer only test
[23:08:40 CEST] <BBB> ok fine nevermind then
[23:36:28 CEST] <cone-469> ffmpeg 03Nedeljko Babic 07master:a9d986c2ced8: avcodec: Minor macro polishing
[23:36:29 CEST] <cone-469> ffmpeg 03Jovan Zelincevic 07master:9e3135f49e45: Edit documentation and versioning for the fixed point AAC decoder
[00:00:00 CEST] --- Thu Jul 23 2015