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

[burek]

[00:00] <beastd|2> Daemon404: honestly i consider looking at the diff in question required most of the times
[00:00] <ubitux> or explain it here and grep your logs at time
[00:00] <Daemon404> beastd|2, doesnt always help
[00:00] <Daemon404> magic numbers, odd changes
[00:00] <Daemon404> etc
[00:01] <beastd|2> OTOH even if the message explains "what" and the diff reflects that, you are often still lost if you do not know the "why"
[00:01] <Daemon404> beastd|2, i like my big commit messages :P
[00:02] <Daemon404> small dissertations <3
[00:05] <beastd> :)
[00:06] <Daemon404> btw beastd, every time i read your nick, i think of: http://images2.fanpop.com/image/articles/44000/the-smurfs_44333_2.jpg?cache=1265517193
[00:06] <Daemon404> not sure why that image is named teh smurfs, since it isnt even from that show.
[00:07] <ubitux> :D
[00:08] <beastd> not sure why you think of it. from which show is that "beast" ? 
[00:08] <Daemon404> care bears
[00:08] <Daemon404> named beastly
[00:08] <beastd> ahh, i see
[00:19] <CIA-63> ffmpeg: 03Michael Kostylev 07master * rea60dfe284 10ffmpeg/libavcodec/x86/ (vc1dsp_mmx.c vc1dsp_yasm.asm): x86: vc1: drop MMX loop filter implementation, which uses MMX2 instructions.
[00:19] <CIA-63> ffmpeg: 03Anton Khirnov 07master * rd371e7b988 10ffmpeg/ (5 files in 3 dirs): lavfi: add lavr-based audio resampling filter.
[00:19] <CIA-63> ffmpeg: 03Anton Khirnov 07master * r012f04a277 10ffmpeg/libavfilter/avfiltergraph.c: lavfi: autoinsert resample filter when necessary.
[00:19] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r1caf614bec 10ffmpeg/: (log message trimmed)
[00:19] <CIA-63> ffmpeg: Merge remote-tracking branch 'qatar/master'
[00:19] <CIA-63> ffmpeg: * qatar/master:
[00:19] <CIA-63> ffmpeg:  lavfi: autoinsert resample filter when necessary.
[00:19] <CIA-63> ffmpeg:  lavfi: add lavr-based audio resampling filter.
[00:19] <CIA-63> ffmpeg:  x86: vc1: drop MMX loop filter implementation, which uses MMX2 instructions.
[00:19] <CIA-63> ffmpeg: Conflicts:
[00:21] <ubitux> hey beastd, do you still have the fix for the docutils path?
[00:22] <beastd> yes
[00:22] <beastd> i need to send it
[00:22] <ubitux> good idea :)
[00:23] <beastd> i had no luck at getting the newer version to run. but maybe someone else will do after i post the patch.
[00:24] <beastd> you are talking about the texi2html relative input path confusion, right?
[00:24] <ubitux> yep
[11:26] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * rd5df0df848 10ffmpeg/libavcodec/mpegvideo_enc.c: 
[11:26] <CIA-63> ffmpeg: mpeg1enc: check input dimensions
[11:26] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:26] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * rf153dfc9e4 10ffmpeg/libavcodec/mpegvideo_enc.c: 
[11:26] <CIA-63> ffmpeg: h263enc: test that dimensions are a multiple of 4
[11:26] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:26] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r1337c6cf15 10ffmpeg/libavcodec/mpeg12enc.c: 
[11:26] <CIA-63> ffmpeg: mpeg1enc: dont use size extension.
[11:26] <CIA-63> ffmpeg: the spec doesnt mention this extension for mpeg1
[11:26] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:26] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r6b0a0dc555 10ffmpeg/libavcodec/mpegvideo_enc.c: 
[11:26] <CIA-63> ffmpeg: mpeg2enc: check input dimensions
[11:26] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:26] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r038eb59b3a 10ffmpeg/libavcodec/mpeg12.c: 
[11:26] <CIA-63> ffmpeg: mpeg2dec: support slice_vertical_position_extension
[11:26] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:35] <mastro_> Hi, I'm on gentoo, Installed ffmpeg-9999 (which means: directly from ffmpeg source code repository -- last version available) then had to rebuild some package, and when trying to rebuild ffmpegsource to fix linking... it fails saying "error: undefined reference to `avcodec_init' " and the full log: http://pastebin.com/2gcZnkcF
[11:35] <mastro_> I checked and avcodec.h doesn't define avcodec_init :)
[11:36] <mastro_> well... maybe I should have used ffmpegsource from sources as well
[11:37] <mastro_> in fact... the last trunk version of ffmpegsource compile
[11:43] <michaelni> mastro_, do you know if avcodec_init() is the only deprecated function ffmpegsource uses ?
[11:45] <JEEB> mastro_, ffms missed which function they checked for their check
[11:45] <JEEB> it was fixed after the 2.17 release
[11:46] <JEEB> oh wait, that's before that...
[11:46] <JEEB> oh, nope
[11:47] <JEEB> they avcodec_init => av_register_all => avcodec_register_all
[11:47] <JEEB> and avcodec_init was still in 2.17
[11:47] <JEEB> and it's only used for the check
[11:48] <JEEB> http://code.google.com/p/ffmpegsource/source/detail?r=641 http://code.google.com/p/ffmpegsource/source/detail?r=642
[11:48] <JEEB> 2.17 tagging was at r637
[11:48] <JEEB> so if you really want to build ffms, you can just switch the function it calls for the test
[11:49] <JEEB> although I thoroughly recommend just building the current svn trunk
[11:51] <mastro_> michaelni, didn't even know it was deprecated :) but looking at the code I think it's the only one
[11:51] <mastro_> JEEB, yep I builded the last svn version
[11:52] <michaelni> hmm if its the only i guess we can just put it back
[11:52] <mastro_> michaelni, let me re-state the above sentence: looking at the portion of code in the configure log it's the only function used...
[11:54] <mastro_> michaelni, I didn't look in the ffmpeg source code, I can tell you it was ffmpegsource-2.17
[11:55] <JEEB> michaelni, nah -- no need. It's only used in that check in configure
[11:56] <JEEB> and the check has since been fixed in the ffmpegsource svn
[11:56] <mastro_> michaelni, JEEB anyway the code that was failing is here: https://ffmpegsource.googlecode.com/files/ffms-2.17-src.tar.bz2
[11:56] <JEEB> yes
[11:56] <mastro_> thank you for your reply :)
[11:56] <mastro_> I compiled the last SVN and it completed
[11:57] <JEEB> it's only used in the configure check, and it has since been changed in the svn to a non-deprecated function
[12:12] <ubitux> michaelni: i just checked the mp3 xing patch using ashowinfo on noxing and xing generated files, the output is the same, except for the "pos" parameter
[12:13] <ubitux> frame checksum are identical, and the number of frames too
[12:14] <ubitux> (i compared {,noxing-}cbr-test-11025.mp3 and {,noxing-}vbr-test-22050.mp3)
[12:14] <ubitux> any idea why the pos is different?
[13:04] <michaelni> ubitux, pos is the byte position in the file if iam not mistaken
[13:05] <michaelni> this changes of cours ewhen a xing header is added
[14:13] <CIA-63> ffmpeg: 03Michael Niedermayer 07release/0.10 * r3fab87edc9 10ffmpeg/libavcodec/pthread.c: (log message trimmed)
[14:13] <CIA-63> ffmpeg: threads: Perform the generic progress cleanup more carefully.
[14:13] <CIA-63> ffmpeg: The cleanup is only done now when
[14:13] <CIA-63> ffmpeg: a picture is returned (assuming that it has to be done when its returned)
[14:13] <CIA-63> ffmpeg: a error is returned (assuming that there will be no further progress on the frame)
[14:13] <CIA-63> ffmpeg: the codec is not h264 (this is still needed due to some deadlocks in realvideo)
[14:13] <CIA-63> ffmpeg: This fixes a decoding regression with 00017.MTS
[14:54] <RushPL> can anybody point me to any video formats or samples where AVFrame's pts member would not be properly set and I would have to use dts/other methods for calculating display time?
[15:31] <ubitux> michaelni: ah right, i'll push this soon then
[16:28] <Compn> RushPL : any raw fmt, f. ex h264 es 
[16:29] <Compn> i think
[16:46] <CIA-63> ffmpeg: 03Carl Eugen Hoyos 07master * r1f2f031c2f 10ffmpeg/libavcodec/libopenjpegdec.c: 
[16:46] <CIA-63> ffmpeg: Set bits_per_raw_sample when decoding libopenjpeg images.
[16:46] <CIA-63> ffmpeg: Reviewed-by: Michael Bradshaw
[16:49] <CIA-63> ffmpeg: 03Clément BSsch 07master * rca297513f0 10ffmpeg/libavformat/mp3enc.c: lavf/mp3enc: support MPEG-2 and MPEG-2.5 sample rates when writing Xing header.
[16:57] <RobertNagy> michaelni: would yadif work as is for planar rgb?
[16:57] <michaelni> it should
[16:58] <RobertNagy> does ffmpeg have any planar RGB PixelFormats?
[16:58] <michaelni> yes
[16:59] <michaelni> PIX_FMT_GBRP*
[16:59] <RobertNagy> ah, I need alpha :(
[16:59] <RobertNagy> anywyas, maybe we shoudl add the GBR formats to the yadif list?
[17:00] <michaelni> yes
[17:00] <michaelni> also adding a planar rgba could be done ...
[17:00] <michaelni> a new pix:fmt i mean
[17:01] <RobertNagy> that would be more optimal for me atleast
[17:10] <michaelni> it shouldnt be hard to add such new pixfmt if you want to do it ...
[17:12] <RobertNagy> how would I do it?
[17:15] <RobertNagy> I guess Iäll dig into swscale
[17:15] <RobertNagy> haven't looked much at that yet
[19:33] <CIA-63> ffmpeg: 03Piotr Bandurski 07master * r6108e1be2f 10ffmpeg/libavcodec/mpegvideo_enc.c: 
[19:33] <CIA-63> ffmpeg: wmvenc: check if width is multiple of 2
[19:33] <CIA-63> ffmpeg: The width of wmv1/2 video must be multiple of 2 or win32 codec will fail to decode it (WMP displays black screen).
[19:33] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:33] <CIA-63> ffmpeg: 03Justin Ruggles 07master * r6f67d9833b 10ffmpeg/libswresample/x86/ (audio_convert.asm swresample_x86.c): 
[19:33] <CIA-63> ffmpeg: libswresample: Implement MMX, SSE4 and AVX 6ch float and int32 packing function.
[19:33] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:33] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r24c0d1583c 10ffmpeg/libswresample/x86/audio_convert.asm: 
[19:33] <CIA-63> ffmpeg: libswresample: unaligned AVX/SSE4 float and int32 6ch pack
[19:33] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:33] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * rb3915c4b70 10ffmpeg/libswresample/x86/audio_convert.asm: 
[19:33] <CIA-63> ffmpeg: libswresample: cosmetics
[19:33] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:21] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r429b964e25 10ffmpeg/libswresample/x86/audio_convert.asm: 
[21:21] <CIA-63> ffmpeg: libswresample-simd: make the converter registers parameters
[21:21] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:21] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * recfdd125f1 10ffmpeg/libswresample/x86/audio_convert.asm: 
[21:21] <CIA-63> ffmpeg: libswresample-simd: rename 6ch pack to what it is
[21:21] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:21] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * rc4047ad9e0 10ffmpeg/libswresample/x86/audio_convert.asm: 
[21:21] <CIA-63> ffmpeg: libswresample: make NOP_N macro less picky on its parameters
[21:21] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:21] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * rca986a06ad 10ffmpeg/libswresample/x86/ (audio_convert.asm swresample_x86.c): 
[21:21] <CIA-63> ffmpeg: libswresample-simd: add ff_pack_6ch_int32_to_float_a_avx and ff_pack_6ch_int32_to_float_a_sse4
[21:21] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:21] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r57bc91c710 10ffmpeg/libswresample/x86/audio_convert.asm: 
[21:21] <CIA-63> ffmpeg: libswresample: Change FLOAT_TO_INT32_N to need 1 register less
[21:21] <CIA-63> ffmpeg: same speed on sandy bridge
[21:21] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:21] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * ra927641e7a 10ffmpeg/libswresample/x86/ (audio_convert.asm swresample_x86.c): 
[21:21] <CIA-63> ffmpeg: libswresample-simd: Add ff_pack_6ch_float_to_int32_a_avx and ff_pack_6ch_float_to_int32_a_sse4
[21:21] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:41] <Daemon404> who would know about teh arcane secrets of -async 1 and how it works?
[21:43] <ubitux> you may check asyncts filter patch from elenril on libav-devel
[21:43] <ubitux> also, if you have there dev channel irc log, ruggles explained it to elenril recently
[21:45] <Daemon404> ic
[22:00] <michaelni> Daemon404, why do you ask about async 1 ?
[22:00] <michaelni> do you want to port that filter to swr ?
[22:00] <Daemon404> no
[22:00] <Daemon404> i have a problem sample where -async 1 makes it output silence infinitely
[22:00] <Daemon404> or at least an extremely long time (24+ hours)
[22:01] <michaelni> did you report it on trac ?
[22:01] <Daemon404> i was gonna try and fix it first
[22:01] <Daemon404> as teh sample is liek 850 mb
[22:01] <michaelni> even better
[22:01] <michaelni> no work for me :)
[22:01] <Daemon404> also it's evil
[22:01] <Daemon404> ffv1 and flac in avi
[22:02] <michaelni> how do the timestamps look ?
[22:03] <Daemon404> i need to check
[22:03] <Daemon404> im not sure how to dump them
[22:04] <michaelni> -fdebug ts is one way that prints them at one point
[22:04] <Daemon404> ok
[22:04] <michaelni> there are other ways and other points
[22:04] <Daemon404> ill go put in my laundry and then check
[22:36] <Daemon404> michaelni, https://japland.org/info.txt <-- any idea what would cause this
[22:40] <Daemon404> [avi @ 0x17e55d40] ff_read_packet stream=1, pts=-9223372036854775808, dts=44, size=14, duration=0, flags=1
[22:40] <Daemon404> ^ and thatd be why
[22:41] <ubitux> i just sent a patch to ffmpeg-devel to avoid printing insane value
[22:41] <ubitux> and print NOPTS instead :p
[22:41] <Daemon404> ubitux, could this cause such infinite silence to be output?
[22:41] <ubitux> no idea
[22:41] <Daemon404> https://japland.org/pts.txt
[22:42] <ubitux> btw, not related, but did you get what you wanted with select filter?
[22:42] <Daemon404> no.
[22:43] <Daemon404> i ended up writing a small ffms2-based program to pipe frame ranges
[22:43] <ubitux> :(
[22:43] <Daemon404> i almost used avxsynth
[22:43] <Daemon404> until i actually tried using it.
[22:43] <ubitux> well
[22:43] <Daemon404> lulz
[22:43] <ubitux> frame range is easy with vf select
[22:43] <Daemon404> it doesnt seek.
[22:44] <Daemon404> and lavf completely lacks indexng
[22:44] <Daemon404> so even if it could, it would not be reliable.
[22:45] <ubitux> ah i see, you wanted to keep processing the rest of the video
[22:45] <ubitux> but applies some processing only to a range of frames?
[22:45] <Daemon404> split video into jobs
[22:45] <Daemon404> encode, join
[22:47] <Daemon404> not being able to seek kind of completely destroyst hat
[22:47] <Daemon404> that*
[22:47] <ubitux> what was the exact operation you wanted?
[22:47] <Daemon404> seek to frame N
[22:47] <Daemon404> decode X frames
[22:48] <Daemon404> in a frame-accurate manner.
[22:59] <ubitux> and then do what?
[22:59] <CIA-63> ffmpeg: 03Clément BSsch 07master * r5edd4fce40 10ffmpeg/libavformat/utils.c: lavf/utils: make use of av_ts2str() to print timestamps.
[23:01] <Daemon404> ubitux, it's a distributed encode essentially
[23:01] <Daemon404> split video int on segments, send off to workers
[23:01] <Daemon404> join at the end
[23:03] <ubitux> ah, ok
[23:03] <ubitux> the seek to frame N can be done, but it's done by decoding the N frames :p
[23:04] Action: kierank blames vfr for that
[23:05] <kierank> but why does lavf need to decode the frames to do that anyway?
[23:05] <Daemon404> kierank, even if it didnt need to
[23:06] <Daemon404> lavf's non-indexed seekign is not trustworthy
[23:06] <Daemon404> certainly nto fraem accurate in soem containers
[23:06] <nevcairiel> its only frame accurate when the container offers enough information to make it so
[23:06] <nevcairiel> so it should be fine in mp4, most likely not in anything else :p
[23:07] <Daemon404> nevcairiel, even then it can be funky :p
[23:07] <Daemon404> ffms2 is pretty good for it, so il lstick to that for now
[23:07] <nevcairiel> yeah, but it needs to index the full file before
[23:07] <Daemon404> yeah but that takes a trivial amount of time
[23:07] <Plorkyeran> when I last tested it (about a year ago), I couldn't find any formats that lavf was always accurate on
[23:08] <Daemon404> indexing 10gb took ~1in on my workstation
[23:08] <Daemon404> 1 min*
[23:08] <Daemon404> worth it for doign a farmed encode on several hours long vid
[23:11] <Daemon404> http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=8&t=454&p=4411 <-- i think this is related to my otehr problem
[00:00] --- Mon May 14 2012