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

[burek]

[00:51] <cehoyos> Could a few peple with different x264 versions installed please test ticket 2165 ?
[00:51] <cehoyos> The two necessary command lines and the input sample are in the ticket.
[00:52] <cehoyos> (Works fine here on OpenSuse with an old x264 distributor build, fails with static Zeranoe binary on Windows.)
[00:57] <cbsrobot> cehoyos: I get the same missmatch with x264 0.129.2245 bc13772
[00:57] <cbsrobot> on osx
[00:57] <cbsrobot> I also get  a crc of 0x92ee27a2
[00:58] <llogan> same. x264 0.129.2230 1cffe9f on Arch.
[00:59] <llogan> *same as cbsrobot 
[01:02] <Daemon404> so im
[01:02] <Daemon404> has anyone tried with x264cli
[01:02] <Daemon404> this ight not even be our  bug.
[01:04] <llogan> there isn't anything to lazy copy n paste
[01:05] <cbsrobot> llogan: format -fr /
[01:09] <Compn> cehoyos : can you review the dxva2 patch on ffmpeg-devel ?
[01:09] <Compn> or just commit it :)
[01:15] <cbsrobot> using: x264 --qp 0 --preset fast --output-csp i422 --output lossless_h264_encoding.mkv lossless_h264_encoding.avi 
[01:16] <cbsrobot> and then: ffmpeg -i lossless_h264_encoding.mkv -pix_fmt uyvy422 -f framecrc -
[01:16] <cbsrobot> I get the correct crc
[01:18] <cbsrobot> when using x264 with "i444", then ffmpeg segfaults as mentionned in https://ffmpeg.org/trac/ffmpeg/ticket/2156
[01:30] <cehoyos> cbsrobot: Why are you using a different command line than I tested?
[01:31] <cbsrobot> cehoyos: first I used the same
[01:31] <cbsrobot> then I tested with x264cli
[01:31] <Daemon404> um
[01:32] <Daemon404> i thought qp 0 was not a valid way to do lossless
[01:32] <Daemon404> because some qp scales go lower than 0
[01:32] <Daemon404> (e.g. 10 bit)
[01:32] <J_Darnley> No, that is crf
[01:33] <JEEBsv> yeah, qp 0 is valid, crf goes to negative
[01:34] <Daemon404> oh
[01:34] <Daemon404> woops
[01:38] <cehoyos> So it fails for everybody with 129 ?
[01:44] <cehoyos> Compn: I don't know anything about dxca2 (I even failed to fix the vdpau regression), nevcairiel offered to have a look when he has time again iiuc.
[01:47] <wm4> the vdpau regression caused by the merge?
[01:53] <cehoyos> Why do you think it was caused by the merge?
[01:53] <wm4> see mplayer mailing list
[01:54] <wm4> someone identified 41bdef1d39584727c9d as commit that breaks mpeg1/2 decoding with vdpau
[01:54] <cehoyos> Iirc (and I do), the regression is caused by a commit that originated in avconv (ie it was unreviewed).
[01:55] <cehoyos> It was actually aaf9d0e
[01:56] <wm4> I wonder how that is possible, because the commit doesn't touch any of the existing decoders
[02:07] Action: J_Darnley curses trac! He now sees why his ffmpeg did not like the "avi" file he downloaded. It starts with "<!DOCTYPE"
[02:10] <michaelni> we dont have xml and html decoders ? ;(
[02:16] <cehoyos> cbsrobot: While the lossless test succeeds with ffmpeg and 128 here, I am unable to get a correct result even for the first frame with x264 cli :-(
[02:19] <Daemon404> have you actually compared how they differ
[02:19] <Daemon404> the yuv
[02:20] <llogan> J_Darnley: yeah, that is annoying. i'd rather have a normal link instead of "preview"
[02:20] <Daemon404> or even read teh x264 docs to see what .128->1.29 signifies
[02:21] <llogan> ...but i'm glad it isn't bugzilla. i'd blow my brains out.
[02:39] <cone-805> ffmpeg.git 03Michael Niedermayer 07release/1.0:f7bf3becf679: Update for 1.0.3
[02:39] <Compn> michaelni : the text decoder should print it... maybe its set as binary file ?
[02:40] <Compn> J_Darnley : you know you're supposed to be able to play the file in some other player before blaming ffmpeg :P
[02:58] <cone-805> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.0.3': unknown revision or path not in the working tree.
[02:58] <cone-805> Use '--' to separate paths from revisions
[02:58] <cone-805> refs/tags/n1.0.3:HEAD: avf_showwaves: fix null pointer dereference
[03:50] <cone-805> ffmpeg.git 03Michael Niedermayer 07master:2338af0fb48e: doc: document aresample:first_pts
[03:50] <cone-805> ffmpeg.git 03Michael Niedermayer 07master:b3ab2810277d: avcodec/x86/cabac: workaround llvm 4.2.1 bug
[05:41] <cone-805> ffmpeg.git 03Michael Niedermayer 07master:0a84174f2d41: mov: prevent double free if the caller replaces the io context.
[07:41] <cbsrobot> michaelni: thanks for fixing #2156
[10:57] <durandal_1707> so if you want apply filter to only part of stream, how do you do it?
[11:10] <burek> michaelni, I've added the number of tests and also introduced a little timeout on mouse over, so that people would only see popup with the log content if they hover their mouse on the link for a second-two, to avoid all those popus to show all the time
[12:07] <durandal_1707> michaelni: give me some introduction for implementing f_conditinal which does separate filtergraph bug 1062
[12:51] <wm4> lol wanting to support wav files without wav header...
[13:25] <juanmabc> man, i must say that seeing the channel from time to time, the project seems to be improving quite at a good rate, keep it going, dudes
[13:25] Action: juanmabc cheers up
[13:30] <durandal_1707> you mean fflogger spam?
[13:41] <juanmabc> durandal_1707: correction, colorful spam
[13:41] <michaelni> durandal_1707, about f_cond, i think it only has to create a filter from its name & args and then pass all calls to it and
[13:42] <michaelni> do some pass through for filter_frame / req_frame when its not active
[13:43] <michaelni> burek, didnt look yet (id have to refind the link) but thanks!
[13:44] <cone-731> ffmpeg.git 03Jindrich Makovicka 07master:570a4a018994: avidec: use sensible error codes instead of -1
[13:44] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:b4a7f4d018aa: Merge commit '570a4a0189946c2c983da41d37fdd67fa13266e7'
[13:53] <durandal_1707> michaelni: i more loking in something like acut filter which cut audio at certains points and apply separate filter to each pieace and resulting output is of same length, like linear editing
[13:54] <durandal_1707> instead of spliting it manually and then applying filters to each componenet and cating it all together again
[13:55] <cone-731> ffmpeg.git 03Diego Biurrun 07master:4af5310d2937: get_bits/put_bits: K&R formatting cosmetics
[13:55] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:766f05520124: Merge commit '4af5310d29379283553bcd9f541a3f6c317f706e'
[14:17] <cone-731> ffmpeg.git 03Luca Barbato 07master:9146e872c643: Revert "fate: Use wmv2 IDCT for wmv2 tests"
[14:17] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:eb2f499e37ee: Merge commit '9146e872c643fb8f20f9043f1b93a3cddfad15c6'
[14:47] <cone-731> ffmpeg.git 03Martin Storsjö 07master:ab587f39b220: rtpenc: Start the sequence numbers from a random offset
[14:47] <cone-731> ffmpeg.git 03Diego Biurrun 07master:4f56e773fe8a: x86: ac3: Fix HAVE_MMXEXT condition to only refer to external assembly
[14:47] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:73b59cc1bad8: Merge commit '4f56e773fe8a554b8c2662650aaf799c2ece2721'
[14:47] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:9774251c45ea: rtpenc: do not use random values for seq when bitexact is requested.
[15:47] <cone-731> ffmpeg.git 03Ronald S. Bultje 07master:4a73fbd9c5d5: vp3/5: move put_no_rnd_pixels_l2 from dsputil to VP3DSPContext.
[15:47] <cone-731> ffmpeg.git 03Michael Smith 07master:0881cbf31498: proresdec: support mixed interlaced/non-interlaced content
[15:47] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:26345acb0e72: Merge remote-tracking branch 'qatar/master'
[16:11] <durandal_1707> michaelni: so it is basically not possible to slice filtergraph input?
[16:25] <michaelni> durandal_1707, iam not sure i understand what you mean by slice. But sure a filter can route different segments to different filters and the combine them
[16:30] <durandal_1707> michaelni: i not interested in combining different parts yet
[16:31] <durandal_1707> michaelni: i just want to split stream in several concated stream
[16:32] <durandal_1707> somethink like reverse of concat...
[16:40] <michaelni> durandal_1707, a filter could open a muxer like the segment muxer and write to several files, or a segment muxer could be at the end of the filter chain and a filter could indicate to it when to start new files, maybe by using a keyframe flag
[16:51] <durandal_1707> michaelni: you dont understand me, i want to cut input audio stream to n pieces and aply each filter to each piece sequentially
[16:52] <durandal_1707> i do not work with multiple files nor output to multiple files....
[16:52] <durandal_1707> basically i need asplit functinality except i need only part of stream not x stream clones
[16:53] <durandal_1707> what is different between JPEG vs MPEG color range?
[16:53] <durandal_1707> JPEG one use all bytes?
[16:54] <michaelni> the difference is where the max / min points are in YCbCR
[16:56] <michaelni> about the audio you can split things as you want and apply filters as you want iam pretty sure its supported but i dont understand what you mean exactly
[16:56] <michaelni> you can split things temporaly or between audio channels
[16:56] <michaelni> you can apply filters as wanted or pass things through
[16:56] <michaelni> and you can pass things on to one or multiple output pads or store in files
[16:57] <michaelni> you could also instanciate a whole filter graph or multiple ones in a filter and pass things throgh them
[16:58] <durandal_1707> michaelni: so what is example for: fade in video - fade out - fade in - fade out?
[16:59] <durandal_1707> michaelni: and what color range have max/min set to 0/255 ?
[17:00] <michaelni> if you want multiple fades in a single video stream, simply using multiple fade filters should work
[17:01] <michaelni> jpeg uses the full 0..255 range
[17:05] <durandal_1707> michaelni: multiple fade filters do not work simply because after fade out everything is black
[17:06] <jeje101> hi to all
[17:06] <durandal_1707> adding options or new filter for this feature is stupid
[17:06] <jeje101> I'm facing a problem using FFMPEG and swscale to decode and display video stream from cameras
[17:07] <durandal_1707> jeje101: than ask it in #ffmpeg
[17:07] <jeje101> depending the resolution of the stream, I can display correctly or not the video stream
[17:08] <jeje101> in fact my problem are when I use 720*576 or 720*288
[17:08] <jeje101> the rendered is look like a stride image pb
[17:09] <jeje101> the stream I want to decode is H264
[17:09] <jeje101> if someone can help me please ...
[17:11] <jeje101> ok sorry It isn't the good room
[17:11] <jeje101> bye
[17:17] <michaelni> durandal_1707, if fade would fade back from black  then multiple should be chainable
[17:18] <durandal_1707> michaelni: and how would that be possible?
[17:21] <michaelni> fade could be changed to support fade to and from black
[17:22] <durandal_1707> fade from black is called fade in, fade to black is called fade out
[17:22] <durandal_1707> adding extra option is silly
[17:22] <durandal_1707> because you would need to add list parsing to each filter that does it
[18:52] <durandal_1707> michaelni: can you share more about various fixes you commit? So I can be sure such fixes are not cosmetical and real bug is resolbed.
[18:54] <michaelni> durandal_1707, which commits?
[18:55] <durandal_1707> any commit that fix crashes/dos/CVE/invalid read/write and so on
[18:55] <durandal_1707> there is FUD spread by quatar peers that your just apply bandaid
[18:56] <michaelni> durandal_1707, where do they say that ?
[18:56] <durandal_1707> here: http://blog.flameeyes.eu/2013/01/crashes-and-dos-what-is-it-with-them-anyway
[18:58] <michaelni> if there are specific commits where someone makes a specific claim then id like to know about it so i can look into it
[18:59] <michaelni> if theres a general "we dont understand ffmpeg code" so it must be wrong then well iam not sure what i could do
[19:13] <burek> michaelni, it's http://ffmpeg.gusari.org/fate2/
[19:14] <burek> btw, I could send it for your review (or whoever is willing to take a look at the code)
[19:14] <burek> so we can copy it to the fate server and test it
[19:14] <burek> it doesn't touch/change any file that is already existing, so it's mostly read-only
[19:15] <burek> it just creates some stats files, in order not to read/grep same data twice
[19:15] <burek> so, I believe it's pretty much safe
[19:17] <michaelni> burek, great, yes please post it, not sure i will review (its not so much my area) but iam happy to put it on the server alongside the existing fate if bcoudurier agrees and it passes review
[19:18] <burek> ok, let me tar/gzip it
[19:23] <michaelni> burek, you need tgz ? its so big ?
[19:23] <michaelni> review is more likely if people can read it , tgz may be a problem here
[19:24] <burek> well, how do you want me to post it
[19:25] <burek> i was thinking like tar/gzip it and send it as attachment (it's not big)
[19:25] <burek> so that anyone can just extract it to his/her webdir and test if he/she wants
[19:25] <burek> but, let me know how to do it in a better way?
[19:28] <durandal_1707> burek: how much it is big when not gzipped?
[19:28] <burek> 72 kb (with images)
[19:28] <burek> 42 kb without
[19:28] <burek> the main index.php is 15 kb
[19:30] <durandal_1707> michaelni: should that be compressed?
[19:31] <Compn> its fine if its that small
[19:31] <Compn> i think mailing list limits to 80K
[19:32] <michaelni> it maybe once was 80k but while i dont remember its exact value its higher now
[19:32] <durandal_1707> i think my patch was bigger than that.....
[19:34] <durandal_1707> ...not it was more than 10 times smaller :) ....
[19:37] <cone-731> ffmpeg.git 03James Almer 07master:e65d8509f065: libm: Add fallback definition for cbrt() using pow()
[19:37] <Compn> yeah it should be higher now
[19:37] <Compn> i think it was bumped to 140K and may even be 200K+ after the server was switched
[19:38] <michaelni> yes 200-300 sounds similar to what i remember
[19:39] <michaelni> at least for some list
[19:39] <Compn> i dont remember that option being in the moderator panel of mailman so it must be in a config somewhere :P
[19:40] <michaelni> your memory sucks then or your eyes ;)
[19:40] <michaelni> i do remember it in the mailman web interface
[19:40] <Compn> could be :)
[19:41] <Compn> Maximum length in kilobytes (KB) of a message body. Use 0 for no limit
[19:41] <Compn> ah yes there it is
[19:41] <Compn> 400K for ffmpeg-devel
[19:49] <mateo`> durandal_1707, michaelni: do you think the aiffenc/id3 patch is ok to be applied ?
[19:57] <durandal_1707> i already gave my opinion multiple times
[19:57] <llogan> yes, 400k for devel and 100k for user
[19:58] <llogan> i increased them both since it was no longer 2004
[19:58] <Compn> haha
[19:58] <Compn> llogan : 65K should be enough for anyone! :P
[19:58] <durandal_1707> it is ok but i do not want to apply it because it is evil
[19:59] <llogan> Compn: you would also get tired of approving >65k messages.
[19:59] <llogan> (or rejecting too)
[20:05] <llogan> http://pastebin.com/jwWArB4g looks like mplayerhq.cn is finally going to be a reality
[20:05] <mateo`> durandal_1707: :(
[20:05] <Compn> i just ignore those letters :D
[20:05] <Compn> arent they basically blackmail ?
[20:06] <llogan> i actually replied to one for the hell of it for a personal domain. it didn't seem blackmailesque but maybe that was the intent
[20:06] <Compn> you didnt get a reply ?
[20:07] <llogan> yes, two replies
[20:08] <Compn> oh
[20:16] <durandal_1707> michaelni: could you be so evil and apply mateo` aiff patch?
[20:20] <cone-731> ffmpeg.git 03Carl Eugen Hoyos 07master:40297a8bdb69: Support solid gray frames when decoding Lagarith.
[20:25] <michaelni> durandal_1707, sure
[20:26] <cone-731> ffmpeg.git 03Stefano Sabatini 07master:7694533fda5d: doc/muxers: remove outdated comment about live flags for the segment muxer
[20:26] <cone-731> ffmpeg.git 03Stefano Sabatini 07master:30a40d4a554c: lavf/segment: provide link to HTML M3U8 draft, also fix mentioned version in docs
[20:27] <cone-731> ffmpeg.git 03Matthieu Bouron 07master:c114414a57b2: lavf/aiffenc: ID3 tags support
[20:28] <cone-731> ffmpeg.git 03Carl Eugen Hoyos 07master:379d03b0c9fd: Fix compilation with --disable-everything --enable-demuxer=loas
[20:36] <cone-731> ffmpeg.git 03Stefano Sabatini 07master:5b10c5e7e4d7: lavfi/showwaves: fix check on showwaves->outpicref
[20:52] <cone-731> ffmpeg.git 03Paul B Mahol 07master:c4274d118b1a: lagarith: return more meaningful error codes
[20:58] <burek> so, I should just attach all the web files (.js, .css, .php) without images (?) as a plain text attachment and send it to the mailing list, right?
[21:01] <burek> here is a dir tree http://i47.tinypic.com/ok7tbo.png
[21:05] <llogan> burek: a non-tarbomb archive with images might be useful for the lazy who might want screw with it locally
[21:06] <llogan> ...as an additional attachment.
[21:07] <burek> so, just to be sure, I should insert all those (text) files as inline attachments and then compress everything and add another (complete) attachment?
[21:07] <burek> (btw, whole thing tar/gzipped is 30 KB)
[21:08] <llogan> burek: sounds good to me
[21:08] <burek> ok
[21:15] <cehoyos> burek: Could you comment on ticket 1387?
[21:15] <burek> sure, just let me finish this first
[21:18] <llogan> burek: i'm surprised you didn't try -input_format for 1387
[21:20] <saste> burek, i recently added some logs to help in case of failure
[21:45] <burek> ok, I've sent the mail to ML, let me see the ticket now
[21:54] <burek> i started testing that h264 input thing only to figure out i'm not testing it with h264 web cam :) anyway in next few days i'll get the cam again and test it
[21:56] <burek> saste, in case of h264 input?
[21:56] <burek> llogan, i will :) thanks for the hint :)
[22:00] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:49b729d3af84: sanm: check image dimensions before using them
[22:05] <saste> burek: in all cases
[22:08] <burek> cool
[22:08] <burek> in regular stderr output or some additional option is needed?
[22:09] <burek> like -report or something
[22:12] <saste> burek: -loglevel debug
[22:12] <saste> i'd like to implement per-context logging level at some point
[22:13] <durandal_1707> michaelni: how that can overflow?
[22:13] <saste> like -loglevel muxer/v4l=debug
[22:13] <burek> saste cool :) thanks :)
[22:13] <burek> well, this is also a big improvement
[22:13] <burek> since, usually, there is a lot of point of possible failure, when working with v4l...
[22:14] <burek> points*
[22:14] <michaelni> durandal_1707, the number of pixels and buffer sizes are calculated by w*h in various forms
[22:17] <durandal_1707> michaelni: ahh, i was thinking about +
[22:19] <llogan> burek: like the guy in #ffmpeg now
[22:23] <burek> llogan, I see, nice :)
[22:29] <durandal_1707> cehoyos: so you reply to ticket for fun?
[22:30] <durandal_1707> you hardcoded aiff demuxer to use 2 and this gives correct output?
[22:34] <cehoyos> I wanted to ask you the same question ;-)
[22:34] <cehoyos> Iirc, I was unable to fix the error message, but if I knew how I would test if "2" works.
[22:38] <durandal_1707> perhaps 16 bits per coded sample means it is using 16k bit rate
[22:38] <durandal_1707> while in fact it is using 2 bits ....
[22:39] <durandal_1707> terminal brain damage....
[22:44] <cehoyos> To a certain, degree that makes sense to me...
[22:46] <durandal_1707> unfortunately files is so small that i hear nothing
[22:49] <cehoyos> This is indeed a problem;-)
[22:49] <cehoyos> The source of the sample is this page afaict: http://www-mmsp.ece.mcgill.ca/documents/AudioFormats/AIFF/Samples.html
[22:51] <cehoyos> It contains another link: ftp://ftp-ccrma.stanford.edu/pub/Lisp/ I believe there is more information if you can find it...
[22:51] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:1bb05797ec27: sanm: remove "duplicate" for loop.
[22:51] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:4c9f35bb7c94: mvdec: use avpriv_set_pts_info() instead of directly setting tb.
[22:55] <durandal_1707> michaelni: that sanm fix may be reason why I could never get other codecs to work properly ....
[23:14] <burek> is there an input option to tell ffmpeg that input video is progressive, although inside the video file the flag has been set as if it was interlaced
[23:14] <burek> something like ffmpeg -deinterlaced -i ...
[23:15] <burek> "According to the production supervisor of the release, the actual video encoded is 1080P30, but since the spec doesn't support that format, it is flagged as 1080i (vc-1)."
[23:15] <cehoyos> What difference should that flag make?
[23:16] <burek> http://ffmpeg.gusari.org/viewtopic.php?f=12&t=766&p=1479#p1479
[23:16] <burek> wait
[23:16] <burek> bad url
[23:16] <burek> http://ffmpeg.gusari.org/viewtopic.php?f=16&t=801
[23:17] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:e6cc3c869b92: mvdec: minor simplification, remove av_inv_q()
[23:17] <cone-731> ffmpeg.git 03Michael Niedermayer 07master:b89815f5199f: mvdec: check channel count.
[23:18] <cehoyos> Sorry, but the question as it is posed ("can ffmpeg play 1080p30") makes no sense at all - ffmpeg decodes 960p40 if you encode your input with 960 lines and 40fps and codec that FFmpeg supports.
[23:18] <cehoyos> I suspect that the OP has a (interlaced) vc-1 stream that FFmpeg does not support. A patch is welcome, there is no simple work-around.
[23:18] <cehoyos> (If he wants to provide a sample, it is welcome.)
[23:19] <burek> ok, thanks :)
[23:19] <cehoyos> (And yes, FFmpeg can better judge if the stream is interlaced than the production supervisor. Or in other words: VC-1 encoder typically sucks
[23:20] <cehoyos> ... A VC-1 encoder typically sucks and encodes even progressive material in interlaced mode.)
[23:20] <burek> great.. :)
[23:21] <cehoyos> s/does not support/does not decode correctly
[00:00] --- Wed Jan 23 2013