Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2014

1 participants
56 discussions

ffmpeg-devel.log.20140212
by burek 13 Feb '14

13 Feb '14

[00:18] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:d3068d25ca6d: avcodec: Add avpriv_mpa_decode_header2() [00:18] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:5669ae84016f: avcodec/mpegaudio_parser: treat codec_id like the other parameters [00:18] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:c33351f3e75d: avcodec/mpegaudio_parser: Delay setting codec_id if it appears wrong [00:18] <michaelni> JEEB, that mp1+mp3 in mp4 thing should be fixed [00:18] <JEEB> oh, thanks <3 [00:18] <michaelni> np [00:19] <JEEB> one less I thing I have to work around elsewhere :) [00:45] <superware> what's the difference between PTS and DTS? [00:45] <Skyler_> PTS is Presentation Time Stamp, DTS is Decode Time Stamp [00:46] <Skyler_> PTS = when it should go on your screen, DTS = when the decoder should eat it (assuming instantaneous decoding) [00:46] <Skyler_> in the absence of B-frames or other frame reordering, PTS generally equals DTS. [00:49] <superware> ok, so for display syncing I need PTS. but frame->pts is constant, maybe I should use frame->pkt_pts? [00:51] <superware> Skyler_? [00:53] <Skyler_> I only know of the generic terminology, I'm not precisely sure of the lavf details [00:54] <superware> ok, thanks [00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:1b05ac220ef1: lavf: add write_uncoded_frame() API. [00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:62106fcc23cf: lavd/alsa: preliminary support of uncoded frame. [00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:d201a0f0f843: lavd/xv: preliminary support of uncoded frame. [00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:dcda5ef1eab5: lavf: add uncodedframecrc test muxer. [00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:8400368f319b: tools: add uncoded_frame test program. [00:59] <cone-297> ffmpeg.git 03Nicolas George 07master:edc7e67669ad: lavf/lavd: version bump and APIchanges for uncoded frames. [00:59] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:058a3d65427e: Merge remote-tracking branch 'cigaes/master' [01:03] <superware> I need to sync video frames for display, how can I go from PTS to time? [01:04] <Skyler_> PTS * timebase = time in seconds [01:06] <superware> video_stream->time_base is { den: 0, num = 429849479 } so 429849479 / 0? [01:08] <Skyler_> that sounds like "completely and totally invalid" [01:13] <superware> does a timebase of 0.02 make sense? [01:15] <Skyler_> superware: that makes sense, that would be 50fps [01:15] <Skyler_> (typically) [01:16] <superware> ah... can't be [01:16] <superware> that's the codec timestamp [01:21] <superware> what a mess, isn't there a safe way to get a specific frame PTS? [01:22] <Skyler_> I think it's generally better to rely on the container timestamps [01:24] <superware> you mean frame->pkt_pts * av_q2d(_video_dec_ctx->time_base) ? [01:31] <superware> the video stream time_base is 429849479/0 and the codec context time_base is 1/50, none makes sense [01:39] <BtbN> 1/50 makes perfect sense [01:42] <superware> the video is 25 fps [01:44] <BtbN> is it interlaced? [01:44] <Skyler_> the timebase being 2x the fps is pretty common for h264 videos [01:44] <Skyler_> but you could have a timebase of 1/1000 for a 25fps video; that would be valid too [01:45] <superware> I don't know if it's interlaced (http://ch0.jurnaltv.md/channel0.flv) [01:45] <Daemon404> "but frame->pts is constant" <-- this sounds very, very wrong [01:46] <superware> frame->pkt_pts seems ok [01:46] <BtbN> fps = avctx->time_base.den / (avctx->time_base.num * avctx->ticks_per_frame); is what i use to get the fps. [01:47] <Daemon404> which is also invalid in many cases [01:47] <BtbN> not that exact code, though. That wouldn't work [01:48] Action: Daemon404 checks that file [01:48] <superware> isn't there a safe way to get a frame's PTS in seconds/milliseconds? [01:49] <BtbN> pts * timebase [01:49] <Daemon404> frame->pts [01:50] <Daemon404> superware, that is a stream right? [01:50] <superware> BtbN: for frame->pkt_pts * av_q2d(_video_dec_ctx->time_base) I'm getting 0.8 (seconds?) between frames [01:50] <superware> @Daemon404: yep [01:50] <Daemon404> superware, do not use pkt_pts [01:50] <Daemon404> it doesnt do what you want [01:51] <Daemon404> im seeing the stream time base correctly set [01:52] <Daemon404> for both streams [01:52] <superware> see http://stackoverflow.com/a/18842961/1549486 [01:52] <Daemon404> well [01:52] <Daemon404> are you going to believe a developer of ffmpeg and heavy downstream user [01:52] <Daemon404> or a random stack overflow answer? [01:52] <superware> "AVFrame.pts is not ever set to anything useful when decoding, ignore it (it might replace pkt_pts in the future, to make the whole mess less confusing, but for now it's like this, for historical reasons mostly)." [01:52] <superware> heh [01:53] <Daemon404> first question: are you calling avformat_find_stream_info() first? [01:53] <superware> yep [01:54] <Daemon404> im able to get the proper pts and stream timebase here from that url [01:54] <Daemon404> so next question: git head [01:54] <Daemon404> ? [01:54] <superware> I see the video (no syncing yet) [01:54] <Daemon404> also i just realized that elenril wrote that stackoverflow answer [01:55] Action: Daemon404 will have to stab him [01:55] <superware> 2.1.3 [01:55] <Daemon404> try head first [01:55] <superware> what's head? [01:56] <Daemon404> git HEAD [01:56] <Daemon404> git master [01:56] <Daemon404> latest git [01:56] <superware> a sec [01:56] <Daemon404> also you should be calling av_frame_get_best_effort_timestam [01:56] <Daemon404> p [01:56] <Daemon404> (i hate it too... such is the API [01:57] <Daemon404> this way you dont need to worry about accessing the right thing [01:59] <Daemon404> av_frame_get_best_effort_timestam(frame) * timebase is givng me correct results [01:59] <Daemon404> note that since it's a stream it has a non-zero starting PTS [01:59] <superware> is av_frame_get_best_effort_timestamp external? [02:00] <Daemon404> external? [02:00] <Daemon404> it's in libavutil/frame.h [02:02] <superware> frame.c -> "they should not be accessed directly outside libavcodec" [02:03] <Daemon404> its telling you to use av_frame_get_best_effort_timestamp() nstead of directly accessing the pts member [02:03] <Daemon404> as i suggested you do above [02:10] <superware> ok, av_frame_get_best_effort_timestamp(frame) * av_q2d(_video_stream->time_base) seems to work! thanks [02:11] <Daemon404> np [02:12] <superware> what's the most basic way to sync the frames? I have a thread that's pulling frames from a queue... [02:12] <Daemon404> the best you can do is probably based on time [02:12] <Daemon404> im not very versed in realtime streamign sync stuff. [02:13] <superware> why is it needed to sync a real-time stream? frames can't come early anyway.. [02:18] <Daemon404> well i dont know much about the playback side of things [02:18] <Daemon404> sync etc [02:41] <superware> thanks [03:24] <superware> I'm using libav to play a live network stream, does it make sense to render frames as they arrive, without any sync? [03:34] <superware> anyone? [06:43] <cone-487> ffmpeg.git 03Michael Niedermayer 07master:a0911b059763: avformat/mov: fix keyframe flags for sample from chromium Issue 340865 [07:28] <smoak> if i have a patch submitted (via git send-email) and it needs to be updated with a new commit, do i just use git send-email --in-reply-to=<message id of the message i am replying to> to send the new commit? or is there a better/preferred way? [07:36] <smoak> or should i start a new thread with the entire patch series? [07:37] <ubitux> as you pleased [07:37] <ubitux> we see both [07:37] <ubitux> if you resend the complete patchset, eventually add a [v2] or something [07:37] <ubitux> there is no real convention though [07:37] <smoak> ok thank you [08:28] <Keestu> hi, av_read_frame (), i understand it reads the packet, but what i do not understand is does the syncronization between server and this api is taken care by framework or do we have to take care ?. Sorry if the question is very basic. i am at beginning level of exploring ffmpeg. [08:29] <Keestu> means does av_read_frame() provides all the streaming data from rtsp server? while(1) { sleep for sometime; now do av_read_frame() }... [10:14] <cone-326> ffmpeg.git 03Clément BSsch 07master:b6c0f07d5a11: avfilter/lut3d: inline whole loop in interpolation function. [10:56] <ubitux> Timothy_Gu: https://github.com/FFmpeg/fateserver [11:04] <ubitux> ah, wait, you wanted the original [11:04] <ubitux> it was hosted on git.mansr.com previously [14:12] <cone-480> ffmpeg.git 03Derek Buitenhuis 07master:bb6b1731eba2: Add libx265 encoder [14:21] <durandal_1707> michaelni: who is working on dts-xll? [14:22] <j-b> durandal_1707: Niels Möller, the nettle guy [14:22] <wm4> durandal_1707: see libav-devel [14:23] <j-b> on a bounty from us [14:23] <durandal_1707> and what he have done? [14:23] <j-b> not much yet [14:23] <nevcairiel> he just started this week it seems [14:23] <durandal_1707> well i have some code i did done [14:24] <durandal_1707> but i then stopped [14:24] <j-b> he is a nice guy and quite competent [14:24] <j-b> and working with merbanan :) [14:25] <merbanan> durandal_1707: I have pointed him to your repo [14:25] <michaelni> and picked libav because "I think it was my colleague who suggested I work with the libav tree" [14:25] <durandal_1707> i just did basic bitstream header parsing [14:26] <durandal_1707> not in the repo [14:26] <JEEB> ok, great :) this cleared a lot around XLL [14:26] <JEEB> ok, I guess since I never even got to writing a parser I'll stop my attempts then [14:26] <JEEB> one less thing on the TODO list I guess [14:26] <durandal_1707> parser? parser should work without any problems [14:27] <j-b> michaelni: sorry, but it makes sense to work around Kostya, since he is the only one who actually wrote a DTS-HD-MA decoder [14:27] <durandal_1707> but libav dts code does not have lot of stuff ffmpeg one has [14:28] <j-b> sure [14:28] <j-b> libav sucks more than ffmpeg on dts decoding [14:28] <j-b> yet the main thing here is xll [14:28] <JEEB> I think someone was already in the process of backporting the dts stuff from FFmpeg [14:28] <nevcairiel> but xll shares dts-hd asset parsing, which is used for all hd extensions, which ffmpeg already has [14:29] <durandal_1707> i just pushed my trivial 200line insertions to xll branch [14:30] <j-b> I don't think the hard part is the asset parsing, but the missing bits [14:30] <nevcairiel> but if someone is already trying to backport, what do i care, i only want the finished feature in the end [14:30] <merbanan> durandal_1707: great I have informed Niels [14:30] <j-b> DTS-HD-MA is the biggest missing codec, as far as I am concerned [14:31] <kierank> yeah the hard part is the things not in the spec [14:31] <nevcairiel> did vlc at least get HD bitstreaming yet? I havent been following it at all :) [14:31] <Daemon404> j-b, we'll still be missing one bluray codec after though [14:31] <kierank> lossless core transform [14:31] <kierank> s/lossless/bitexact [14:31] <nevcairiel> Daemon404: eac3? [14:31] <j-b> Daemon404: MVC? [14:32] <Daemon404> no [14:32] <j-b> nevcairiel: hdmi passthru? [14:32] <Daemon404> some chinese crap [14:32] <nevcairiel> j-b: yea [14:32] <Daemon404> which is actually in the spec [14:32] <Daemon404> iirc [14:32] <j-b> nevcairiel: I have a branch for this [14:32] <j-b> Daemon404: wut? [14:32] <Daemon404> no, really. [14:32] <JEEB> I don't remember such from the spec [14:32] <nevcairiel> Daemon404: well it still lacks proper eac3 support too. It can only decode the ac3 "core" but not the eac3 dependent frames with the extra channels, so you get only 5.1 and not 7.1, similar to DTS-HD just not lossless :) [14:32] <Daemon404> kierank might know [14:33] <kierank> DRA audio [14:33] <kierank> chinese dts [14:33] <JEEB> oh [14:33] <nevcairiel> although this shouldn't be too hard. I thought about trying it once, but time... [14:33] <j-b> http://en.wikipedia.org/wiki/Dynamic_Resolution_Adaptation ? [14:34] <kierank> yeah and the spec is in chinese iirc [14:34] <durandal_1707> i'm sick of shitty codecs [14:34] <nevcairiel> that seems kinda stupid, accept something into an international spec like the blu-ray spec which doesnt even have a english spec? :p [14:36] <j-b> did they include 4k in the new bluray spec? [14:37] <nevcairiel> last i heard they are still working on a new version with 4k [14:38] <ubitux> is Kyle on irc? [14:39] <nevcairiel> kyle who? [14:39] <JEEB> kierank, hmm, interestingly I can't see DRA mentioned in version 2.01 of the spec. Granted, this is pretty old by now :P [14:39] <kierank> it's relatively recent yes [14:39] <j-b> JEEB: added in 2.3 [14:39] <JEEB> ah [14:40] <nevcairiel> isnt there like version 5 by now [14:40] <nevcairiel> might be confusing profiles with spec versions [14:41] <j-b> I thought we were at 2.4 or 2.5 [14:42] <ubitux> nevcairiel: schwarz [14:42] <JEEB> Part 3: Audio Visual Basic Specifications Ver.2.5 June 2011 [14:42] <JEEB> in ROM format version 3 [14:47] <j-b> Daemon404: interesting, I did not know about this codec. [14:49] <Daemon404> i apologize for informing you [14:49] <cone-480> ffmpeg.git 03Diego Biurrun 07master:25a1ba814ad8: log: Have function parameter names match between .c and .h file [14:49] <j-b> Daemon404: :) [14:49] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:74744790a366: Merge commit '25a1ba814ad80056247fd357ec4c6911324a3f66' [14:50] <j-b> Daemon404: more bounty ideas to waste VideoLAN money \o/ [14:50] <Daemon404> lu [14:50] <Daemon404> lul [14:52] <kierank> parc asterix > bounties :) [14:54] <j-b> untrue [14:56] <cone-480> ffmpeg.git 03Diego Biurrun 07master:4a7d3837b4dd: buffersrc: Have function parameter names match between .c and .h file [14:56] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:1bc3f1b73dff: Merge commit '4a7d3837b4dd17fff270b55166597c093204e542' [15:00] <kierank> j-b: if I were you i'd write some code that added some bass to DTS and say it was a lossles decoder [15:00] <kierank> and see how many people actually nitce [15:00] <kierank> notice* [15:01] <JEEB> lol [15:01] <j-b> none [15:01] <Daemon404> i need lossless audio for my $2 d->a convert and 2.5 jack [15:02] <Daemon404> it is absolutely necessary [15:13] <kurosu_> Perhaps you meant "sampled at more than 2*20KHz" ? [15:15] <Compn> i'd like to see the vlc http seeking bounty fixed :\ [15:18] <cone-480> ffmpeg.git 03John Stebbins 07master:462d5e8e6c05: aacdec: set AVFrame sample_rate [15:18] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:8c5fece11fcb: Merge commit '462d5e8e6c050eae7cbb1f2d5c34628088bd0eb6' [15:23] <Compn> maybe i just need to pass vlc the option to use ffmpeg's network code [15:25] <Compn> blah, libav.org 's redesign does not work for older opera browser [15:26] <Compn> oh nevermind, some odd opera setting was on [15:26] <Compn> ah, page zoomed in too far did it, i see. [15:28] <Compn> yep, zoom too far in , same with firefox [15:28] <Daemon404> it's almost as if you should use software from this decade [15:28] <Compn> hey my firefox is updatd [15:28] <Compn> try zooming into the page [15:28] <Daemon404> i dont zoom in [15:29] <Compn> do it! [15:31] <Compn> also happens if your browser window is skinny [15:31] <Compn> i guess if you have lots of windows open and read browser in a limited window size [16:15] <cone-480> ffmpeg.git 03Janne Grunau 07master:0ebb523f0723: asfdec: check ff_get_guid() return values during seeking [16:15] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:d32926db7f42: avformat/riff: return error code from ff_get_guid() [16:15] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:5634c9518f07: Merge commit '0ebb523f072322972ea446616676fff32e9603c6' [16:26] <kurosu_> michaelni: no need to look at the lfe_dir patch for now, I see you are right for the scale, and will continue investigating from there [16:26] <michaelni> ok [16:29] <kurosu_> J_Darnley: by the way, my comments on asm are border-line nitpicky, only the inner loop might have an impact [16:29] <kurosu_> for x86_64 and shift parameter, you're right: it's only win64 abi that only uses up to 4 gps for parameters [16:31] <kurosu_> it's just that callee-saved parameters may cause noticeable extra work when too numerous but that again is probably not worth it [16:35] <J_Darnley> Regarding your comment about inc/dec. I have read conflicting things about the how useful they are. Various arguments about speed. All of which is probably horribly outdated when you are writing sse4 code. [16:36] <cone-480> ffmpeg.git 03Andrew Kelley 07master:0c0825659652: asfdec: short-circuit seeking to the start of stream [16:36] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:f73901f815d0: Merge commit '0c082565965258dca143767cc6cb25e38b6e9ea3' [16:43] <kurosu_> J_Darnley: yes - the only thing to consider nowadays is maybe "how long is the generated instruction" for code/cache size reasons [17:02] <cone-480> ffmpeg.git 03Janne Grunau 07master:f5d92d9cab07: asfdec: fix seeking with fragmented packets [17:02] <cone-480> ffmpeg.git 03Michael Niedermayer 07master:3e8b17f05b91: Merge remote-tracking branch 'qatar/master' [17:05] <Compn> why the other ciphers task in gsoc ? i mean if they are used for some video format or network protocol, it might be nice to list that in there [17:06] <Compn> i'm not against it of course, just curious [17:55] <kurosu_> michaelni: well, prescaling the coeff table is slower... [17:55] <kurosu_> this is strange [17:56] <michaelni> for both C and asm ? [17:57] <kurosu_> asm only, C is negligible [17:57] <kurosu_> the order of operations in the C code has a bigger impact... [17:59] <kurosu_> (note: fate-dts passes, so it's not a consequence of doing things improperly) [18:00] <kurosu_> measuring the whole loop in lfe_interpolation_fir: [18:01] <Daemon404> 31 [18:01] <Daemon404> woops. [18:01] <kurosu_> before: 1367 now: 1378 [18:01] <kurosu_> testing win32 [18:02] <kurosu_> faster... [18:02] <kurosu_> 1462 -> 1428 [18:03] <kurosu_> well, the change makes sense, let's just say these are the consequences of random things that will change at the next commit [18:03] <kurosu_> the bigger issue is that it needs a (small) rewrite of the neon part [18:05] <michaelni> agree on random [18:12] <kurosu_> for the other change, about pre-shuffling the coeffs so as to reduce the shuffling inside of the function [18:13] <kurosu_> I think this needs a x86/arm/...-specific function to achieve the proper shuffling [18:13] <kurosu_> and an output buffer for the shuffled coeffs [18:13] <kurosu_> where would you put this buffer? decoder context or dsp context ? [18:30] <michaelni> all existing buffers we have are in the decoder contexts if iam not missing one [18:30] <michaelni> or rather if i havnt forgotten one [18:31] <kurosu_> nothing for mdct/fft ? [18:32] <Daemon404> afaik all the fft and mdct buffers are in codec contexts [18:32] <Daemon404> at least when i looked a year or so ago [18:32] Action: Daemon404 may be wrong [18:32] <kurosu_> I thought there were permutations that were arch-specific, but I don't remember either [18:32] <kurosu_> anyway... [18:33] <kurosu_> win32: no difference, win64: slower... [18:33] <kurosu_> not surprising that it changes nothing: that's 2 shuffles in a function that takes 340 cycles [18:34] <kurosu_> I don't think this one is worth it [18:36] <kurosu_> (ie not in loop, and probably completely masked by ooo execution) [19:52] <llogan> ubitux: his nick is Zeranoe [19:52] <llogan> IIRC [20:16] <ubitux> llogan: ah.. [20:16] <ubitux> ok [00:00] --- Thu Feb 13 2014

1 0

ffmpeg.log.20140212
by burek 13 Feb '14

13 Feb '14

[00:45] <superware> what's the difference between PTS and DTS? [01:03] <superware> I need to sync video frames for display, how should I go from PTS to time? [01:10] <Logicgate> hey guys everytime I run ffprobe it head a huge header with useless information [01:10] <Logicgate> http://pastebin.com/Tu8r8tnb [01:10] <Logicgate> I'm assuming I have an old version of ffprobe [01:11] <Logicgate> Since I can't format the data in JSON, or can't run the -v quiet setting [01:12] <Logicgate> is there a workaround? [01:13] <llogan> Logicgate: get a non-ancient ffprobe [01:14] <Logicgate> yeah [01:14] <llogan> both supply ffprobe, IIRC [01:17] <Logicgate> thanks llogan [01:18] <Logicgate> both links don't work [01:19] <Logicgate> ffmpeg.gusari.org is down [01:19] <Logicgate> and johnvansickle's builds time out when downloading [01:20] <klaxa> ffmpeg.gusari.org isn't down [01:21] <klaxa> at least not from here [01:21] <Logicgate> it's good now [01:21] <Logicgate> I had to reload a few times [01:21] <Logicgate> now just unpack that and ./ffmpeg? [01:21] <Logicgate> and it'll install it? [01:21] <klaxa> no need to install [01:22] <klaxa> unpack it and then run it [01:22] <Logicgate> that's so simple. [01:22] <Logicgate> that's too simple [01:22] <Logicgate> lol [02:12] <Logicgate> Invalid data found when processing input [02:12] <Logicgate> What could cause this [02:12] <Logicgate> I'm running the latest static build trying to apply a watermark to an mp4 [02:12] <Logicgate> ./ffmpeg -i media/test.mp4 -vf 'movie=media/1_1392167471_52faca2f392af.png [watermark]; [in][watermark] overlay=0:0 [out]' w_test.mp4 [02:12] <Logicgate> that's the command. [02:16] <Logicgate> Do the static builds have all the codecs? [02:19] <Logicgate> llogan, I figured it out :P [02:19] <Logicgate> thanks [02:19] <llogan> and you don't need to use the movie multimedia source filter: ffmpeg -i input.mp4 -i logo.png -filter_complex "[0:v][1:v]overlay[out]" -map "[out]" -map 0:a -codec:a copy output.mp4 [02:53] <Hello71> which is preferable: -acodec, -codec:a, -c:a [03:23] <superware> I'm using libav to play a live network stream, does it make sense to render frames as they arrive, without any sync? [03:26] <relaxed> Hello71: latter [03:27] <relaxed> but they're all synonymous [03:35] <superware> anyone? [04:35] <wolfman2000> Evening. On Mac OS X Mountain Lion or higher, is there a standard way to compile and distribute a binary for a repository? Or is there a different method preferred these days? [04:36] <wolfman2000> err, distribute a compiled library. A *.a file [07:33] <Keestu> hi , how to get the pitches of a texture? [09:05] <__raven> hi [09:05] <__raven> ustream rtmp streaming: input output error on ingest server - how to find out why? [09:41] <Keestu> hi, av_read_frame (), i understand it reads the packet, but what i do not understand is does the syncronization between server and this api is taken care by framework or do we have to take care ?. Sorry if the question is very basic. i am at beginning level of exploring ffmpeg. [10:08] <__raven> ustream rtmp streaming: input output error on ingest server - how to find out why? [10:14] <__raven> anything going wrong with headers/container: different on windows and linux versions windows streams to ustream but it does not appear and on other server the stream is played back only when i stop the stream so its only buffered - whats that? [13:16] <__raven> ustream rtmp streaming: input output error on ingest server - how to find out why? [13:16] <__raven> anything going wrong with headers/container: different on windows and linux versions windows streams to ustream but it does not appear and on other server the stream is played back only when i stop the stream so its only buffered - whats that? [14:30] <davez> Hi all [14:31] <davez> I am using ffmpeg to add srt subs to a mp4 file using [14:31] <davez> "./ffmpeg -i in.mp4 -f srt -i in.srt -c:v copy -c:a copy -c:s mov_text out.m4v" [14:31] <davez> it works a bit [14:31] <davez> some lines do not show up in the file: [14:32] <davez> probably because i receive the following message: [14:32] <davez> invalid UTF-8 in decoded subtitles test; maybe missing -sub_charenc [14:32] <Fusl> can someone tell me if there's a way to exit after 3 hours runtime? [14:32] <davez> i have checked the srt file and the missing lines seem normal to me [14:32] <Fusl> i'm dumping a mmsh stream which often freezes and then the ffmpeg process gets stuck [14:33] <Fusl> i can't even ctrl^c the ffmpeg process anymore if it's freezed [14:33] <davez> ps grep kill ? [14:33] <Fusl> davez: i want to do it automatically [14:33] <Fusl> i tried with timeout 3h in front of it but then the ffmpeg doesn't even begin to read the mmsh stream [14:35] <davez> lol fusl [14:36] <davez> this looks okay to me [14:36] <davez> http://www.ict.griffith.edu.au/anthony/software/timeout.sh [14:40] <Fusl> someone said i should uses -shortest to prevent such freezes but it didn't work :( [14:43] <davez> i probably would solve it through making a file when it starts and a 2nd script that sleeps 180 x 60 seconds then checks if the still exists [14:43] <davez> is so killall ffmpeg ;) [16:32] <svyatko> hi guys, anyone here good with ffmpeg pipes? i need some help piping output of one ffmpeg to another one [16:32] <Hello71> !ask [16:32] <Hello71> ballocks [16:35] <svyatko> i have the following: [16:35] <svyatko> WORKS fine: ./ffmpeg -i 'udp://239.0.0.5:5000' -c:v copy -c:a copy -f nut pipe:| ./ffmpeg -f nut -i pipe: -c:v copy -c:a copy -f flv [16:36] <svyatko> DOESNT WORK: ./ffmpeg -i 'udp://239.0.0.5:5000' -c:v copy -c:a copy -f nut pipe:| ./ffmpeg -f nut -i pipe: -c:v copy -c:a copy -f flv | ./ffmpeg -f nut -i pipe: -c:v copy -c:a copy -f flv [16:37] <svyatko> getting the following error for the second pipe output: [nut @ 0x2b91420] No main startcode found. pipe:: Invalid data found when processing input [18:28] <bmhm> Hi there. I'd like to run ffmpeg & ffserver on a raspberry pi. Any chance of doing this? Does ffmpeg encoding support hardware encoding yet? [18:30] <clever> not that i know of [18:30] <clever> but i have made a mostly working hardware decode [18:30] <clever> b frames mess it up right now, and it chews thru a ton of memory bandwidth [18:32] <bmhm> clever: i only need encoding, though [18:32] <clever> where will the video come from? [18:35] <__raven> ustream rtmp streaming: input output error on ingest server - how to find out why? [18:35] <__raven> anything going wrong with headers/container: different on windows and linux versions windows streams to ustream but it does not appear and on other server the stream is played back only when i stop the stream so its only buffered - whats that? [18:36] <bmhm> clever: usbtv driver /dev/video0 [18:36] <clever> bmhm: and that outputs raw video frames or pre-encoded video? [18:36] <bmhm> raw. sadly. [18:36] <clever> ah [18:36] <clever> so that will eat a ton of usb bandwidth as well [18:36] <bmhm> Stream #0:0 -> #0:1 (rawvideo -> libx264) [18:37] <clever> id recomend you start by looking at the video encoding example in /opt/vc/src/ [18:37] <bmhm> well, usb bandtwidth - the heck with it. [18:37] <bmhm> I think a raspberry pi is not a good choice. [18:37] <clever> ive had plans to make a rpi based upnp transcoder [18:37] <bmhm> any ideas for a small form factor encoding station, headless linux? [18:37] <clever> decode the video, resize it, re-encode it, stream it over upnp to less capable devices [18:38] <clever> http://www.raspberrypi.org/phpBB3/viewtopic.php?f=70&t=61565 [18:39] <clever> bmhm: if you subscribe to this thread, youll get more info if i finish my ffmpeg patches and start on the encode side [18:39] <bmhm> ok thanks. [18:39] <clever> its currently able to hardware decode video and play it back via dispmanx [18:40] <clever> but b frames mess up the order of the output [18:40] <bmhm> clever: any idea for small form factor encoding hardware, running linux? [18:40] <bmhm> I could use my tv station pc, though [18:41] <clever> either get the encoding example from the hello_pi stuff to work, or do software encoding on a system with decent cpu power [18:41] <clever> or get a proper tv capture device like a pvr-150 [18:41] <clever> or one of the usb based encoders [18:42] <bmhm> can you msg me some please? [18:42] <clever> http://www.hauppauge.com/site/support/support_pvr150.html [18:42] <clever> this is a pci based capture card, coax/svideo/composite in, mpeg2 out [18:43] <bmhm> pci wont help on araspberry pi [18:43] <clever> yeah, you would have to go with a normal x86 desktop [18:43] <clever> but the cpu power wont matter [18:43] <clever> ive done it on a P2 400mhz [18:43] <bmhm> I want webm anyway [18:44] <clever> is the source analog or digital tv? [18:44] <bmhm> analog, composite. [18:44] <clever> http://www.mythtv.org/wiki/Video_capture_card#Analog_Hardware_Encoder_Cards [18:44] <bmhm> I currently use this device: http://linuxtv.org/wiki/index.php/Easycap#USBTV007_EasyCAP [18:44] <clever> Most hardware-encoding cards output an MPEG-2 stream, which can simplify backing up to DVD. [18:45] <bmhm> WinTV-PVR-USB2 sounds promising [18:45] <clever> acording to the mythtv wiki, most hardware encoders produce mpeg2 [18:49] <bmhm> aww they are too expensive [18:49] <bmhm> its cheaper to find a small x86 pc [18:51] <clever> but that may not have enough cpu power to encode [18:54] <bmhm> if i want to convert to webm/vp8 anyway? [19:02] <bmhm> clever: i think I'll stream h264 to the web then, using a hauppauge hd-dvr 1/2. [19:02] <bmhm> I might be able to grab one from ebay for a low budget [19:04] <ChocolateArmpits> There is a number of deinterlace filters available. Do any others produce better image quality when compared to yadif ? [19:09] <bmhm> clever: thanks, hauppauge will probably do for now. No webm/vp8, but heck, mp4/h264 will also do. [19:16] <wodim> hello [19:16] <wodim> how can I split a VOB file using the dvd_nav_packet stream it already has? [19:26] <llogan> ChocolateArmpits: have you tried w3fdif? (I haven't). [19:27] <llogan> also see mcdeint [19:38] <YuGiOhJCJ> Hello, I got some "ALSA buffer xrun" messages when I am capturing audio and video over the network (i.e., an output file stored on a NFS share or an output stream like twitch.tv) but when the output is a local file (on my hard disk drive) I got no "ALSA buffer xrun" messages... Do you know how to avoid this message with ffmpeg over the network ? [19:39] <YuGiOhJCJ> My command is: $ ffmpeg -y -f alsa -i default -f x11grab -r 10 -s 640x480 -async 1 -i :0.0 -strict -2 -c:a aac -c:v libx264 -pix_fmt yuv420p -preset ultrafast -s 640x480 -threads 0 -ar 44100 -b:a 64k -b:v 64k -bufsize 64k -f flv out.flv [19:41] <llogan> YuGiOhJCJ: does it create a bad output when the xruns occur? [19:41] <YuGiOhJCJ> yes, the audio is out of sync [19:42] <YuGiOhJCJ> I am wondering if it is an ALSA problem or a FFmpeg problem... Maybe both [19:42] <llogan> do you get xruns if you only encode the audio? [19:42] <YuGiOhJCJ> Not tested [19:43] <YuGiOhJCJ> I will tell you that in few seconds [19:46] <YuGiOhJCJ> No if I encode only audio, I got no more xruns [19:47] <ChocolateArmpits> llogan, well I haven't really done any testing with available ones yet, but maybe others have, so that's what I'm asking [19:47] <YuGiOhJCJ> My new command is: $ ffmpeg -y -f alsa -i default -strict -2 -c:a aac -c:v libx264 -pix_fmt yuv420p -preset ultrafast -s 640x480 -threads 0 -ar 44100 -b:a 64k -b:v 64k -bufsize 64k -f flv out.flv [19:47] <llogan> ChocolateArmpits: if you're too lazy to test then ask on the ffmpeg-user mailing list. [19:48] <ChocolateArmpits> llogan, I'm not lazy, I'm at home so don't have access to my workstation or the source material I will be doing this on [20:13] <wodim> how can I read the contents of a dvd_nav_packet stream? [20:17] <YuGiOhJCJ> llogan, and so what it means that I don't get xruns if I encode the audio only? [20:19] <llogan> YuGiOhJCJ: http://trac.ffmpeg.org/ticket/615 [20:23] <YuGiOhJCJ> yes I have already read it and the "cehoyos" solution gives me "ALSA buffer xrun" too [20:24] <YuGiOhJCJ> The command is: ffmpeg -f x11grab -r 25 -s 288x216 -i :0.0 -f alsa -i default -strict -2 -acodec aac -vcodec mpeg4 -y rec.mkv [20:28] <YuGiOhJCJ> llogan, the problem is the same with this command than with my first command: when the output is a local file I got no "ALSA buffer xrun" messages but when the output is over the network then I got these messages. [20:29] <llogan> does using "-threads 1" reduce or increase the xruns? [20:29] <llogan> is your output bitrate faster than your bandwidth? [20:29] <YuGiOhJCJ> when I read /proc/cpuinfo, I see I have only 1 core [20:29] <YuGiOhJCJ> threads is for using more core isn't it ? [20:30] <llogan> referring to your console output will indicate the number of threads that libx264 automatically allocates [20:30] <YuGiOhJCJ> no my bandwith is ~100kB I have tested with the iftop command which is very useful [20:31] <llogan> or you can try using two ffmpeg processes: one each for capturing video and audio and then somehow use a third to mux the outputs. [20:31] <llogan> i'm just guessing here which is probably fairly obvious [20:31] <YuGiOhJCJ> my last command: ffmpeg -f x11grab -r 25 -s 288x216 -i :0.0 -f alsa -i default -strict -2 -acodec aac -vcodec mpeg4 -threads 1 -y rec.mkv [20:32] <YuGiOhJCJ> and I got these "ALSA buffer xrun" messages when I am on an NFS share but not if I am in a local directory like "/tmp" [20:32] <llogan> i was referring to libx264, not mpeg4, which is probably not what you wanted in the first place [20:32] <llogan> i don't know. [20:33] <YuGiOhJCJ> ok I try with the first (that I prefer) [20:34] <YuGiOhJCJ> my last command is: ffmpeg -y -f alsa -i default -f x11grab -r 10 -s 640x480 -async 1 -i :0.0 -strict -2 -c:a aac -c:v libx264 -pix_fmt yuv420p -preset ultrafast -s 640x480 -threads 1 -ar 44100 -b:a 64k -b:v 64k -bufsize 64k -f flv out.flv [20:34] <YuGiOhJCJ> (threads is 1 instead of 0) [20:35] <YuGiOhJCJ> and I got these "ALSA buffer xrun" messages when I am on an NFS share but not if I am in a local directory like "/tmp" [20:36] <YuGiOhJCJ> This solution of using two ffmpeg processes could be the solution (and the third to mux the outputs)... Is it difficult to do? [20:38] <llogan> not with "local" files that can be remuxed after they are done encoding [20:47] <YuGiOhJCJ> ah ok but my final objective is to stream on twitch.tv... As I got these "ALSA buffer xrun" messages, I try to find the reason by changing the output to local files. But if it works only for thoses files it is not very interesting for me [20:48] <YuGiOhJCJ> (in fact I can already avoid these messages by changing my current working directory from "/home" that is a NFS share to "/tmp") [20:48] <YuGiOhJCJ> but for the stream, I have not this choice [20:50] <YuGiOhJCJ> I am wondering why working over the network makes appeared these "ALSA buffer xrun" messages... Probably because it is slower. [20:52] <YuGiOhJCJ> Do you think I should create a ticket for this problem? [20:56] <YuGiOhJCJ> 64 kbit/s is a very ridiculous bitrate and should work over the network without any problem [20:59] <bmhm> does WinTV-HVR-950Q has a hardware encoder, i.e. does it output an mpeg stream? [22:17] <__raven> rtmp to ustream drops framerate extremely at 2mbit any experience with that? [22:28] <BtbN> How do i remove subtitles when transcoding with the ffmpeg cli util? [22:56] <kutemo> BtbN, use "-sn" to disable subtitles. [22:57] <BtbN> ah, that's even better than the map solution i cam up with [23:55] <rufsketch1> hello everyone [23:56] <rufsketch1> I'm trying to encode multiple files into a mosaic of video [23:56] <rufsketch1> however, the files are still being generated while I do this. [23:56] <rufsketch1> and so ffmpeg runs to the end and then dies with the error [h264 @ 0x3051440] no frame! [23:57] <rufsketch1> how can I make ffmpeg either wait for the next frame or specify a limit on how many frames ffmpeg is allowed to encode per second. [23:57] <rufsketch1> I've tried using -re to tell it to encode at the speed of the input [23:58] <rufsketch1> and that does slow the encoding speed down. but not to the correct 30 fps [23:58] <rufsketch1> it brings it down to 60fps [00:00] <rufsketch1> relaxed: http://pastebin.com/raw.php?i=5HwTLXZk [00:00] --- Thu Feb 13 2014

1 0

ffmpeg-devel.log.20140211
by burek 12 Feb '14

12 Feb '14

[00:05] <michaelni> llogan, made one myself [00:05] <michaelni> logo i mean not f.book [00:08] <michaelni> http://ffmpeg.org/ff64logo.png [00:52] <BBB> Skyler_: sure - I've put them on my list to try, just haven't gotten to it yet [00:57] <Skyler_> BBB: I think some of the copies (e.g. 1881-1886) can be replaced with COPY64 [00:57] <Skyler_> since you're copying 0,0 to 1,0 and 0,1 to 1,1 etc [00:57] <Skyler_> I guess we'll want to make sure we align the mvs [01:17] <BBB> I believe I wnted to try to remove them, since I believe we're not using them [01:18] <BBB> but I had to get the decoder functional first and then forgot [01:46] <cone-427> ffmpeg.git 03Matt Oliver 07master:1ff42685fee2: avformat/libssh: Fix libssh defaulting to shared linkage. [03:44] <cone-427> ffmpeg.git 03Marton Balint 07master:8e41240047db: lavfi/frei0r: load plugins from lib64 folders as well on 64bit builds [03:55] <cone-427> ffmpeg.git 03James Almer 07master:6c12b1de064d: x86: add missing XOP checks and macros [09:29] <pross-au> any reason why gsoc2011 is not mentioned on the 2014 page. that was the year there was split b/tween libav & ffmpeg. [09:50] <superware> in my video player I have two threads, one for decoding and one for playback, should I queue packets or frames in the decoding thread? [10:04] <thardin> superware: do what ffplay does [10:09] <superware> thardin: but it uses SDL, I'm not [10:12] <thardin> so? [10:12] <thardin> that's just a difference in how you display the frames, not how you decode/queue them [10:12] <superware> well, maybe unrelated. but ffplay.c is VERY complex (for me) [10:13] <thardin> from experience I'd say it's better to adapt something that works (like ffplay) than to write something new [10:13] <thardin> unless you're doing it just for fun :) [10:13] <superware> but it does much more than I need, I just need to sync video frames for display, no audio [10:13] <superware> heh [10:16] <thardin> so just strip the audio stuff :) [10:16] <superware> should I queue packets, process them on a dedicated thread and queue video frames and process them on yet another thread? [10:17] <superware> I think it's more than that, it seems ffplay relies on audio for sync [10:17] <thardin> not if the file doesn't have audio it doens't [10:17] <thardin> but I say demux and decode in the same thread, enqueue for another thread [10:18] <superware> enqueue packets or frames? [10:18] <thardin> frames [10:21] <superware> so the dequeue thread is pulling a frame, how much time should it delay before rendering it considering it's pts and prev frame pts? [10:26] <thardin> the difference between the two? [10:27] <thardin> or rather: compare the first frame's pts to your wall clock [10:27] <thardin> then sync subsequent frames to the clock [10:28] <superware> but on a live stream frames can come late, sometimes on time, but never early [10:29] <thardin> oh. uh, dunno [10:29] <thardin> delta-pts I suppose [10:30] <thardin> keep in mind there's a rather course granularity to sleep() [10:32] <superware> what do you mean? [10:34] <thardin> try sleep(25):ing in a loop and see how accurate it is [10:34] <thardin> or something like that [10:35] <thardin> you'll have to experiment [11:24] <superwar> thardin: how can I convert from one AVPixelFormat to another? sws_scale seems to also do it, but I don't need to rescale. [11:26] <thardin> just use the same dimensions [11:26] <thardin> iirc sws is quite clever [11:26] <thardin> and will "get" that you only want to change pixel format [11:26] <superwar> so there's no dedicated way? [11:27] <nevcairiel> no, swscale is the only thing we have [11:27] <nevcairiel> if you provide the same dimensions, it'll not scale [11:27] <nevcairiel> well, some pixel format conversions require scaling [11:28] <nevcairiel> because the size of the chroma planes change [11:28] <thardin> if you convert say 4:4:4 to 4:2:0 it's scale chroma down [11:28] <thardin> I think [11:28] <thardin> yeah [11:28] <superwar> oh [11:31] <superwar> is there a way to decode straight to say AV_PIX_FMT_BGR0 ? [11:31] <thardin> codecs decode what they decode to [11:31] <thardin> except certain special cases [11:32] <superware> I see [11:32] <thardin> so for instance jpeg can decode to 4:2:0, 4:2:2 or 4:4:4 depending on input [14:07] <Compn> why are people putting svq3 in mkv [14:11] <rcombs> why are people putting svq3 in *anything* [14:19] <thardin> I much prefer svq1 [14:19] <wm4> Compn: what muxing method? vfw? [14:21] <wm4> ubitux: about frame based subtitles, I think we should add a DISPOSITION flag to signal frame based, and in that case make the timestamp the frame number (with a time base to get a "reasonable" fallback fps) [14:22] <ubitux> timestamps are always frame number anyway [14:22] <ubitux> (for frame based subs) [14:23] <wm4> yeah, that should just be documented, not that it's broken later because it was merely implicit [14:33] <Compn> wm4 : no idea, going from bug 3256 [14:33] <Compn> https://trac.ffmpeg.org/ticket/3256#comment:10 [14:33] <Compn> ffmpeg remux [14:33] <wm4> ok [14:33] <wm4> QT muxed [14:33] <wm4> disgusting [14:49] <Daemon404> libx265 wrapper is done -- just need soe bugs fixd upstram before i submit it [14:52] <ubitux> libx265 does stable release? [14:52] <Daemon404> they do, but thats not the issue :P [15:03] <Daemon404> ubitux, im mostly waiting for a working pkg-config :P [15:04] <Daemon404> and soname [19:06] <JEEB> did someone here e-mail or something that mp3 gets misdetected as mp1 sample to cehoyos? because he e-mailed me and seems to have very bad understanding of what multimedia frameworks are [19:07] <JEEB> I mean, I _know_ lavf/lavc developers never think of these libraries being used for separate components instead of one monolithic thing like mplayer/mplayer2/mpv/VLC etc. [19:07] <JEEB> but this level of herp and derp kind of makes me do an inner barrell rol [19:07] <JEEB> *roll [19:08] <wm4> yeah, mp3 detection has many issues [19:09] <wm4> and all of these players you listed actually do have extra abstraction layers between the libav* libs [19:09] <JEEB> yes but they generally don't have anything else in there that could get used [19:10] <wm4> somewhat true [19:10] <JEEB> first exchange http://up-cat.net/p/4b24e3fb , second exchange http://up-cat.net/p/29f910f2 , and then the latest http://up-cat.net/p/18eef479 [19:10] <wm4> mplayer and vlc have tons of other decoders, especially audio decoders, though [19:10] <JEEB> I hope someone can at least take that as funny .-. [19:10] <JEEB> because I'm kind of getting aggravated [19:11] <wm4> wait, so if you give libavcodec "mp1", it decodes it fine even if it's really mp3? [19:11] <JEEB> yes [19:11] <wm4> funky [19:11] <JEEB> it switches automagically or something [19:12] <JEEB> I bet cehoyos will just say "lower the MS filter's merit" or "heighten your merit" [19:12] <JEEB> which has nothing to do with the actual issue [19:13] <JEEB> and do note, that I am actually being nice [19:13] <JEEB> And yes, of course I could just "if (format==mp4 && codec==mp1) codec [19:13] <JEEB> = mp3;" but that is a horrible hack. I am just wondering if more of [19:13] <JEEB> the stream could be analyzed for a more correct tagging of the stream [19:13] <JEEB> (or something like that). If not, then of course other alternatives [19:13] <JEEB> have to be looked into on my side. [19:13] <wm4> can mp1 be in mp4? [19:13] <wm4> (also damn these names) [19:13] <JEEB> in theory yes [19:14] <wm4> then the situation is rather fucked up [19:14] <JEEB> since that specific way of muxing is for all of ISO/IEC 11172-3 [19:14] <JEEB> which contains "mp1", "mp2" and mp3 [19:17] <wm4> but yeah, he's trying to discuss away the real issue [19:17] <wm4> instead of looking how to fix it [19:19] <JEEB> ok, I don't even know how to reply to his newest reply [19:20] <JEEB> http://up-cat.net/p/ba0c2cad [19:21] <Daemon404> "u r fagget" [19:21] <Daemon404> proper internet response [19:21] <JEEB> someone bring me a 12pack of beer and I will do that [19:21] <JEEB> otherwise I'm way too good-minded [19:24] <wm4> lol [19:25] <wm4> so why doesn't he put that proposed hack into lavf? [19:25] <wm4> if mp1 in mp4 supposedly does not exist in the wild [19:26] <ubitux> < JEEB> did someone here e-mail or something that mp3 gets misdetected as mp1 sample to cehoyos? // he back logs this channel [19:26] <JEEB> ok [19:45] <JEEB> http://up-cat.net/p/b937564b [19:46] <JEEB> I feel horrible after writing this [20:20] <ubitux> Daemon404: sorry i missed the changelog entry on top [20:23] <Daemon404> i noticed [20:23] <Daemon404> :P [20:28] <wm4> JEEB: lol [20:29] <JEEB> wm4, there have been such times only rarely when I have felt the urge to punch someone in the face [20:30] <wm4> reminds me of sending 1 line patches to ffmpeg-devel, and somehow ending up in flames [20:31] <Daemon404> JEEB, welcome to carl [20:31] <Daemon404> join the job [20:31] <Daemon404> there are liek a dozen of us [20:33] <nevcairiel> wm4: why do you think i so rarely upstream my changes :d [20:40] <ubitux> Daemon404: btw, LGPL? [20:41] <JEEB> Daemon404, I don't want to have negative feelings about the guy, but it seems like I can't help it :P [20:41] <Daemon404> ubitux, x265 is gpl [20:41] <Daemon404> making the wrapper lgpl is pointless. [20:42] <Daemon404> oh indeed it's lgpl [20:42] <Daemon404> in which case it's a no-op anyway [20:42] <Daemon404> :D [20:42] <ubitux> you have a gpl "dep" [20:43] <ubitux> if you keep it, [20:43] <ubitux> update LICENSE [20:43] <Daemon404> it is a d ep [20:43] <Daemon404> x265 is GPL [20:43] <ubitux> then add it to the appropriate section in LICENSE [20:43] <ubitux> sorry i didn't notice earlier [20:43] <Daemon404> gotcha [20:44] <JEEB> libx264 wrapper is LGPL IIRC as well [20:44] <Daemon404> at least you didnt tell me i a missed aligning an = [20:44] <ubitux> having the wrapper LGPL is useful for one reason [20:44] <ubitux> if the library get relicensed [20:44] <ubitux> you don't have to query every single contributor to the wrapper [20:47] <Daemon404> lol [21:03] <BtbN> Is it possible to tell the configure script to generate a static ffmpeg binary? disable-shared enabled-static doesn't achive that. [21:04] <nevcairiel> it should [21:04] <BtbN> the libav* libs are static, but it still depends on a lot of shared system libs [21:05] <ubitux> BtbN: http://ffmpeg.gusari.org/static/ [21:05] <ubitux> see how those are done [21:05] <nevcairiel> probably needs --extra-ldflags="-static" [21:06] <nevcairiel> maybe also in cflags, idk [21:10] <Daemon404> careful [21:10] <Daemon404> that with static link glibc [21:10] <Daemon404> which is Not Good [21:10] <Daemon404> (on glibc systems anyway) [21:11] <nevcairiel> he wanted static [21:11] <nevcairiel> too bad its not so trivial to link extra libs static but libc shared [21:14] <BtbN> it's linking in stuff like libpulse 4.0, which isn't available. So for a test binary static glibc should be ok [21:14] <BtbN> isn't available on most systems [22:34] <ubitux> Daemon404: you sure you sent v2? [22:34] <ubitux> i still see trailing comma after {NULL}, bad project copyright etc [22:37] <Daemon404> fuck i forgot the copy right [22:37] <Daemon404> and i purpsely left { NULL }, [22:37] <Daemon404> purposely* [22:38] <Daemon404> we do this a lot throughout the codebase [22:39] <ubitux> that's just bad copy paste [22:39] <ubitux> and we don't at least in lavfi [22:40] <ubitux> there is no reason to keep that comma since we will never add an entry after it [22:41] <ubitux> [~/src/ffmpeg]- git grep '{ *NULL *}$'|wc -l [22:41] <ubitux> 487 [22:41] <ubitux> [~/src/ffmpeg]- git grep '{ *NULL *},'|wc -l [22:41] <ubitux> 155 [22:44] <Daemon404> sure ok [22:44] <Daemon404> i will both before i push [22:44] <Daemon404> ive fixes teh licensed locally already [23:03] <cone-297> ffmpeg.git 03Maxim Poliakovski 07master:d6d78518018a: g2meet: factor out seeking to the chunk end [23:04] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:852dcf336bc5: Merge commit 'd6d78518018a12fb495baab5663708a830f3aab6' [23:12] <J_Darnley> Did somebody forget to upload a few HEVC files to th fate sample server? [23:18] <michaelni> J_Darnley, try again [23:19] <J_Darnley> Yes, rsync copied the files [23:20] <cone-297> ffmpeg.git 03Kostya Shishkov 07master:6477449243db: g2meet: make JPEG tile decoder operate on 8x8 block mask [23:20] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:bde58d990158: Merge commit '6477449243db4aab15a4db356e8354c60b5366ec' [23:29] <J_Darnley> and now fate finishes without error [23:37] <cone-297> ffmpeg.git 03John Stebbins 07master:52771346dc78: lavc: set AVFrame pkt_pts and reordered_opaque in reget_buffer [23:37] <cone-297> ffmpeg.git 03Michael Niedermayer 07master:707a07f3c2b5: Merge remote-tracking branch 'qatar/master' [00:00] --- Wed Feb 12 2014

1 0

ffmpeg.log.20140211
by burek 12 Feb '14

12 Feb '14

[00:12] <Guest68016> Hello, is it possible to stream my desktop live via http? [04:20] <z1lt0id> I'm writing a bash script and I want to a dummy encode of an aac file to see what bitrate it would turn out to be. Is there a way to write the information to a text file of the overall bitrate with ffmpeg? [04:21] <ezekiel> z1lt0id: ffprobe [04:22] <ezekiel> and/or use -stats output during encoding [04:24] <z1lt0id> ill check out the command thanks :) [07:42] <Logicgate> hey guys [07:42] <Logicgate> I need to install ffmpeg properly [07:43] <Logicgate> I had a hell of a time last time doing it [07:43] <Logicgate> any good tutorials for CentOS [09:30] <superware> I'm building a video player for live streams with libav*, how should I sync the frames for display? does it matter that the stream is live and packets can't "come early"? [09:33] <luc4> Hello! I wrote some code to mux a h264 stream in avcc format into mp4 using annex b with ffmpeg. I parse the stream for the various nal types (0x65, 0x61, 0x68, 0x67 etc...), I create the annex b and I use ffmpeg to mux. Now I just encountered a stream that has none of these nal formats but types like 0x27 and 0x21. Anyone who knows what these nals are and how I should give them to ffmpeg? [09:36] <superware> or... how should I sync a live video stream I'm getting from libav? [09:46] <superware> I have a decoding thread and a playback thread, should I queue packets or frames in the decoding thread? [10:46] <luc4> Hello! Can I somehow mux a rtp h264 stream into an mp4 using ffmpeg? [11:14] <cyberef> is there anyway to determine the actual duration of a video-file that is not complete? Like for example if you aborted the upload of it in a FTP-transfer [11:16] <Keestu> Dear all, are they any ported file of ffplay.c for SDL2.0 ? [11:57] <excalibr> How do you achieve the same effect as adding opt --engage no_cue_duration,no_cue_relative_position in mkvmerge? [14:27] <vak> hi [14:27] <vak> are the avconv questions appropriate to be asked here? [14:28] <spaam> #libav is a better place. [14:28] <vak> thanks! [14:38] <DelphiWorld> hi FFmpeg's [14:39] <DelphiWorld> ffmpeg -f mpegts -i http://172.16.32.100:8081/bysid/12 -deinterlace -vcodec libx264 -vb 256k -acodec libfdk_aac -ab 48k -ar 44100 -f flv rtmp://myRTMPD:1935/myapp/MyTV [14:39] <DelphiWorld> is working *perfectly* [14:40] <DelphiWorld> except of sometime it's get down [14:40] <DelphiWorld> i dont know why [14:41] <relaxed> Logicgate: http://johnvansickle.com/ffmpeg/ [14:43] <relaxed> DelphiWorld: this has nothing to do with your issue, but instead of "-deinterlace" use "-vf yadif". [14:44] <DelphiWorld> relaxed: hehe, first time i heard about it. can you give a clue about it or the diference? [14:45] <DelphiWorld> relaxed, also is my settings is acceptable for that kind of streaming? [14:48] <DelphiWorld> changed:) [14:49] <relaxed> -vf yadif is a much better deinterlacer [14:50] <DelphiWorld> relaxed: just the naming made me laugh a bit [14:50] <DelphiWorld> ok so what about the other params, are they good for live encoding? [14:50] <relaxed> DelphiWorld: Have you read https://trac.ffmpeg.org/wiki/StreamingGuide ? [14:51] <DelphiWorld> relaxed: a lot, but streaming & transcoding are not the same:-P [14:53] <relaxed> well, there's a section entitled "Transcoding/repeating" [14:54] <DelphiWorld> relaxed: i'm allready on it:-) [15:27] <DelphiWorld> the ffmpeg is still auto shutting down! [15:45] <DelphiWorld> [mpeg2video @ 0x3164560] 00 motion_type at 22 26 [15:45] <DelphiWorld> Clue less lol [17:58] <hexhaxtron> Hello! I'm using this command: for filename in *; do ffmpeg -loop 1 -r 2 -i rise.png -i "$filename" -c:v libx264 -preset medium -tune stillimage -crf 18 -c:a copy -shortest -pix_fmt yuv420p "$filename".mkv; done [17:58] <hexhaxtron> And I get: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [17:58] <hexhaxtron> What should I do? [17:58] <hexhaxtron> Is it the picture size? [18:33] <bmhm> Hi all. I'm getting invalid frame sizes which make ffmpeg and afterwards ffserver crash. Please see: http://pastebin.com/aSqEzkqP [18:35] <bmhm> wrong paste, see http://pastebin.com/gxncpZQx [18:50] <bmhm> Wow, the shipped USB cable is bad. [19:05] <bmhm> What does ffserver's StartSendOnKey do? [19:55] <ramin> hey I try to concat two videos. I have absolute paths in the required text file, but he ffmpeg doesnt get it says then of course that the file do not exist (folder of the txt file+absolutepath) [19:56] <rafajafar> hey I was wondering, is it possible to remove the black borders from a video using ffmpeg? When I do crop detect it's frame by frame. Anyone know of a fast way to just accept crop detects suggestion and then scale to a size? [19:56] <ramin> one entry looks like this file 'C:/davideocliper/data/input/video/rendered/idO07rk5YVY/scene-1.avi' [20:30] <bmhm> rafajafar: ffmpeg -i input.mp4 -vf crop=1280:700 -y output.mp4 [20:33] <rafajafar> yeah but I want to auto detect black borders and get rid of them, then resize the video to be normalized [20:34] <rafajafar> cropdetect filter is pretty straight-on, but it only tells me what needs to be cropped, it doesn't actually do the cropping... was wondering if there's a single command, or maybe two, that will let me crop and then resize an entire video [20:38] <rafajafar> thanks, though, bmhm [20:39] <Mavrik> rafajafar, I don't think so [20:39] <Mavrik> several reasons really :) [20:40] <rafajafar> it appears crop detect works frame by frame, for one, so if it detects two different values per frame it would throw off the enitre video resolution [20:41] <rafajafar> still would prefer an average crop or even a chain command where frame by frame is crops and THEN resizes [20:41] <rafajafar> just trying to normalize the video for computer vision work [20:41] <Mavrik> rafajafar, yeah, the thing is that ffmpeg filters don't really have info about context, they can only process frame by frame [20:42] <Mavrik> so cropdetect can't really tell you an "averate" crop rectangle, only rectangle for current frame [20:42] <Mavrik> which can differ wildly (e.g. you can have all-black frames with text in it) [20:42] <Mavrik> that's why it can't do processing online as well - you're not allowed to change video resolution inside stream [20:42] <rafajafar> right, so I definitely wish I could detect->crop->resize each frame in one step [20:42] <Mavrik> yeah but you cant because frames have to be exact same size :) [20:42] <rafajafar> hence the resize [20:44] <rafajafar> this would speed things up immensely if ffmpeg had a way to do it rather than relying on my homebrew border detection algorithm and openCV [20:44] <rafajafar> c'est la vie [21:18] <jangle> what format does ffmpeg expect audio data like g.711 frames to be, or in other words, is there an equivalent to h264 annex b for g.711 audio? [22:14] <guthead> can ffmpeg take a still frame image and zoom in and pan around and generate a video, or do I need to use something like imagemagick to actually generate the frames first and feed them into ffmpeg? [22:22] <llogan> guthead: yes, ffmpeg can probably do that with various filters and expressions [00:00] --- Wed Feb 12 2014

1 0

ffmpeg-devel.log.20140210
by burek 11 Feb '14

11 Feb '14

[00:46] <saste> why is trac still down? [00:47] <beastd> saste: Is it? [00:47] <saste> beastd, here I get a Service Temporarily Unavailable [00:48] <saste> https://trac.ffmpeg.org/ [00:48] <beastd> saste: sounds cached :( [00:50] <saste> well time to sleep, will check it tomorrow [00:50] <saste> god night [01:28] <cone-814> ffmpeg.git 03Janne Grunau 07master:b37effdc5283: mxfdec: free descriptor extradata in .read_close() [01:28] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:ec1a1be54fa7: Merge commit 'b37effdc52835e121a0e259e57273a19f9cd61a3' [02:27] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:2f6eec65acc9: vp8: fix PPC assembly to work if src_stride != dst_stride [02:27] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:d84f1a60e07c: Merge commit '2f6eec65acc953faed3951fb8f1eabed830fdd2f' [03:54] <cone-814> ffmpeg.git 03Kostya Shishkov 07master:e95018b694c0: dnxhd: Support DNx444 [03:54] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:51290068fa12: Merge commit 'e95018b694c0774477abec5bbf86ecc7946a9a28' [04:11] <cone-814> ffmpeg.git 03Luca Barbato 07master:246d3bf0ec93: hevc: Conceal zero td [04:11] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:03911c418f1a: Merge remote-tracking branch 'qatar/master' [10:24] <ubitux> huh, you need to be registered to access relevant ARM documentation?.. [10:24] <ubitux> > NEON Programmers Guide [10:24] <ubitux> > This document is only available in a PDF version to registered ARM customers. [10:24] <ubitux> wth. [11:07] <Mavrik> ;) [11:56] <cbsrobot> ubitux: thanks for the ebur128 commit [11:57] <ubitux> thanks to you :p [12:26] <cone-890> ffmpeg.git 03Anton Khirnov 07master:d711d839ca67: doc/APIchanges: fill in missing hashes and dates [12:26] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:2e99867a4e43: Merge commit 'd711d839ca6714a5ef5b53ee51bc7632e62cf203' [12:29] <cbsrobot> anybody knows a fast way to blend two 48-bit (or 64) per pixel images with alpha channel ? [12:31] <cone-890> ffmpeg.git 03Anton Khirnov 07master:cca4742a5e66: doc/APIchanges: mark the place where 9 was branched [12:31] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:ee2c1e6dd337: Merge commit 'cca4742a5e663cfe4dbd71f01f0c0fb042fddc1d' [12:39] <cone-890> ffmpeg.git 03Anton Khirnov 07master:38893dc028e4: pcmdec: replace a reachable assert with an error check [12:39] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:6732f4350d08: Merge commit '38893dc028e458eaf3f906833d4ee515689edb7e' [12:50] <cone-890> ffmpeg.git 03Anton Khirnov 07master:b5f851ed7e59: FATE: force FLAC in the lavf ogg test [12:50] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:1e5656bf8a8e: Merge commit 'b5f851ed7e59f88b4130a420033d9fe191ec9e2f' [12:59] <cone-890> ffmpeg.git 03Guillaume Martres 07master:f548f9f9e7a2: hevc: update conformance streams [12:59] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:919791f99dc8: Merge commit 'f548f9f9e7a2a08c780e88dac63b9d5d2c55efb0' [13:03] <cone-890> ffmpeg.git 03Marton Balint 07master:6421111b52de: lavf: allow av_find_best_stream to return AV_DISPOSITION_*_IMPAIRED wanted_streams [13:32] <cone-890> ffmpeg.git 03Anton Khirnov 07master:b36bc81ccaa2: avplay: add support for seeking to chapter marks [13:32] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:6fb8684a24cd: Merge commit 'b36bc81ccaa2fc85dc4bae7dc546c71e8833573d' [13:47] <cone-890> ffmpeg.git 03Anton Khirnov 07master:ad7f2b69a546: lavf: rewrite the av_interleaved_write_frame() doxy [13:47] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:58fdc6db6c72: Merge commit 'ad7f2b69a546ec65ef6b11e1a0fd58e6bb66bc4b' [13:52] <cone-890> ffmpeg.git 03Anton Khirnov 07master:4c750599509c: lavf: rewrite the av_write_frame() doxy [13:52] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:6fd7ea44b2e1: Merge commit '4c750599509c3973afbe2850953a1fb963f696e5' [14:10] <cone-890> ffmpeg.git 03Anton Khirnov 07master:54f7e79d4706: lavf: add some basic documentation of the muxing process [14:10] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:c84280b09ce6: Merge commit '54f7e79d4706a8343dad1d8da51b7d3d3b2cd3b2' [14:19] <cone-890> ffmpeg.git 03Anton Khirnov 07master:18c896be3d8e: lavf: extend / improve the AVFormatContext doxy [14:19] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:ec8e232b53b3: Merge commit '18c896be3d8e926ef806e7de29c4a168d7763389' [14:31] <cone-890> ffmpeg.git 03Christophe Gisquet 07master:682b2a809b44: build: fix examples compilation when EXESUF is not empty [14:31] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:1c1bb203ddae: Merge remote-tracking branch 'qatar/master' [15:22] <Daemon404> is saste away lately? [15:22] <ubitux> he's not as active as he used to be but he was here yesterday [15:23] <Daemon404> ah ok [15:23] Action: Daemon404 will wait [17:02] <wm4> ubitux: I got a microdvd subtitle file that uses "{1}{1}23.976" to declare the frame rate [17:16] <wm4> ubitux: it's probably read correctly, but it's also displayed for some reason [17:16] <ubitux> mmh [17:17] <ubitux> it should probably be skipped yes [17:18] <j-b> llogan: btw, the link to the git howto was fixed, as you asked. [17:18] <ubitux> wm4: can you find someone interested in contributing to subtitles code in ffmpeg? [17:19] <ubitux> wm4: it seems i'm busy with more fun stuff nowadays :( [17:20] <wm4> ubitux: I don't know anyone either, but I could write a patch for this issue (if I know how...) [17:20] <wm4> I'm not entirely sure why this line is displayed at all [17:20] <wm4> probably my own funny-ass logic for subtitles with no end time [17:20] <ubitux> so, it's in libavformat/microdvddec.c [17:21] <ubitux> and then well, i think you would just add a "continue" in the pts_info = ... set thing [17:21] <ubitux> just like the {DEFAULT}... actually [17:22] <wm4> sounds like a good idea [17:22] <ubitux> btw, while at it, i suppose you want to add the "subpts" option just like in aqtitle [17:22] <ubitux> (libavformat/aqtitledec.c) [17:23] <ubitux> and eventuallyy add a FRAME_BASED kind of flag [17:23] <wm4> can't find the string subpts in libavformat/aqtitledec.c [17:24] <ubitux> subfps [17:24] <ubitux> sorry [17:24] <wm4> doesn't look useful [17:24] <ubitux> why? [17:24] <ubitux> didn't you open a ticket for this? [17:25] <wm4> I can use this to override the subtitle fps? [17:25] <ubitux> so you could force the subfps to the video frame rate [17:25] <wm4> I don't even know the video frame rate when opening the demuxer [17:25] <ubitux> well i guess you would do that to override the pts_info thing [17:26] <wm4> I have to know two things: 1. is the format timestamp based or frame based? 2. if it's frame based, how do I get the frame number from the (made up) timestamps [17:26] <wm4> 2. could be solved by always using a fixed timebase (like 23.976) [17:26] <wm4> for 1., a flag has to be added, as you said [17:27] <wm4> which is an api change [17:27] <ubitux> the pts are generated for the given FPS [17:28] <ubitux> so it's just like if the subtitles format was containing timestamps for you [17:28] <ubitux> it shouldn't be different [17:28] <ubitux> so i don't understand the problem [17:28] <wm4> a bit roundabout, but could work [17:31] <ubitux> wm4: the time base is set to 1/fps, and pts are actually frame number [17:31] <ubitux> but if you rescale those pts to that timebase [17:31] <ubitux> you actually get the timestamps [17:31] <wm4> I know [17:31] <BtbN> should i set the pts or the dts to AV_NOPTS_VALUE? Currently i set dts to AV_NOPTS_VALUE, but i get "Encoder did not produce proper pts, making some up.", but the pts looks ok. [17:31] <ubitux> just like any other subtitles format [17:31] <ubitux> so what's the problem? [17:32] <BtbN> should i just set the pts to AV_NOPTS_VALUE, and set the dts to the current pts instead? [17:32] <ubitux> i mean what this difference is breaking? [17:32] <wm4> ubitux: well, I need a way that works and that is uniform across subtitle formats [17:32] <ubitux> wm4: it's uniform? [17:32] <wm4> aqtitle apparently uses 25 fps by default, microdvd uses 23.976 [17:32] <ubitux> it doesn't matter for you [17:32] <wm4> unless you guarantee that the timestamp is always the frame number [17:32] <ubitux> it's 25 by default because the format stat so iirc [17:33] <ubitux> wm4: ?? [17:33] <ubitux> wm4: with any subtitle format you're supposed to rescale the pts based on that timebase [17:33] <ubitux> frame based or not that will give you the same correct ts [17:33] <ubitux> most subtitles format use different tb [17:34] <ubitux> srt will use 1/1000, ass 1/100, aqt 1/25, .. [17:34] <ubitux> or maybe i'm missing something? [17:34] <wm4> I need to know the case when a subtitle (format) depends on the video FPS [17:35] <ubitux> wwhy? [17:35] <wm4> which is the case with microdvd _if_ it doesn't set the fps [17:35] <wm4> because that's how shit works [17:35] <wm4> download a microdvd file for PAL, and it's implictly 25 fps [17:35] <wm4> download one for NTSC, it's implicitly 23.976 [17:35] <wm4> unless the file contains a FPS header [17:35] <ubitux> ah you're trying to actually support the frame-based thing without the timestamp abstraction from ffmpeg? [17:36] <wm4> what [17:36] <ubitux> if you mean you want to change that hardcoded 23.976 value, you would just add a "subfps" option just like aqtitle [17:37] <ubitux> and try to set it all the time if you know that value [17:37] <wm4> but I don't know the video fps when opening the subtitle file [17:39] <ubitux> i'm sorry, i'm probably under neurosis because i just don't understand why you want to know that [17:40] <ubitux> and how knowing that the subtitles are actually frame based will allow you to do [17:40] <wm4> I can process the subtitle later [17:40] <ubitux> unless you actually want to be very frame exact and actually blend the subtitles per frame [17:41] <ubitux> wm4: btw, are you able to change the time base of the demuxer? [17:41] <ubitux> (i wonder if the subfps option is actually necessary if you can do that) [17:41] <wm4> ubitux: I don't think just setting the timebase from outside is allowed [17:41] <ubitux> ok [17:42] <ubitux> sounds legit [17:42] <ubitux> then we may want a subfps in microdvddec to force a different fps [17:42] <ubitux> and also, we can add a FRAME_BASED flag in the codec desc. for those codec [17:42] <ubitux> telling the frame->pts will actually be the frame number [17:42] <wm4> currently I have this cute hack to detect frame based: http://privatepaste.com/d9a464bcfc [17:43] <ubitux> what? [17:43] <wm4> indeed [17:43] <ubitux> why didn't you hardcode the codec name instead? :p [17:43] <wm4> yeah, maybe it should _also_ check for the codec name [17:43] <ubitux> anyway, i still don't get it [17:44] <ubitux> also? meh [17:44] <wm4> I'll try to explain it again [17:44] <wm4> microdvd files normally contain frame numbers, right? [17:44] <ubitux> yes [17:44] <wm4> these are video frame numbers (during which the subs should be displayed) [17:44] <wm4> so, at which time a subtitle appears obviously depends on the video frame rate [17:45] <wm4> crappy design, but this is how this format works [17:45] <ubitux> so far, i understand [17:45] <wm4> so if you use the "wrong" video file with the sub file, the subs will be mistimed [17:45] <wm4> (but that's by design) [17:45] <ubitux> right [17:46] <wm4> to do this correctly, the subtitle code in the applciation has to know that this format is frame based [17:46] <wm4> because libavformat always returns timestamps, not frame numbers [17:46] <wm4> you could special case this by checking the codec name [17:47] <wm4> say, if the codec name is microdvd, then assume it's frame based [17:47] <ubitux> right right [17:47] <ubitux> so that was my initial suggestion [17:47] <wm4> now here starts the problem: some microdvd files actually declare a FPS [17:47] <ubitux> you actually want to handle the pts as frame id yourself [17:47] <wm4> this is the FPS of the video the subs were timed against [17:47] <ubitux> and blend the subtitle based on frame [17:48] <wm4> and in this case, you don't want to treat this subtitle as frame based, even though it's microdvd [17:48] <ubitux> mmh [17:48] <wm4> and yes, setting the subfps option (like aqtitle has it) to the video frame rate would handle this correctly [17:48] <wm4> because microdvd.c just overrides the FPS with the value in the file header [17:49] <wm4> but my application opens all files at start, so I don't know the video FPS yet [17:49] <wm4> now that I think about it, I could set the subfps option to something absurd [17:49] <wm4> and detect the frame based case by this [17:49] <ubitux> haha [17:50] <ubitux> you can just add a flag to the codec desc [17:50] <ubitux> that's fine with me [17:50] <wm4> like I just explained, whether it's frame based or not depends on the _file_ [17:50] <ubitux> but that won't give you the default fps, which you seem to need [17:50] <wm4> at least for microdvd [17:52] <ubitux> ah, hell yeah i understand now [17:53] <ubitux> mmh [17:54] <ubitux> wm4: do you see a pratical solution for this except the subfps hack to detect explictely set fps? [17:56] <wm4> hm maybe AV_DISPOSITION_ could be abused to set a frame-based flag? [17:56] <wm4> there's already random crap in it (like AV_DISPOSITION_ATTACHED_PIC), so why not [17:56] <ubitux> and that flag would be set by microdvd (and unset if FPS is set in the file)? [17:57] <wm4> yes [17:57] <wm4> as for the default frame rate; I'm not sure [17:57] <ubitux> i'm not sure about AV_DISPOSITION but that could be discussed [17:57] <wm4> subfps might also work, but it'd have tricky semantics... [17:57] <wm4> I mean, it's not obvious that a demuxer must ignore subfps if the data is not frame based [18:00] <ubitux> so anyway, the semantic of microdvd is not 23.976 when unset [18:01] <ubitux> microdvd can actually be fps based only when FPS are explicit.. that's pretty news to me :( [18:02] <ubitux> wm4: and btw, the AVOptions don't allow you to read values from the context? :-° [18:02] <wm4> sure [18:03] <wm4> that could be used [18:03] <ubitux> because in that case we can use those avoptions [18:03] <ubitux> to communicate the explicit set fps [18:03] <wm4> you just have to make sure the used option names don't collide with anything else [18:05] <ubitux> gtg bbl [18:15] <cone-890> ffmpeg.git 03Zhang Rui 07master:4958628ba69e: avformat/concatdec: pass the interrupt callback on [18:56] <llogan> j-b: thanks! [19:05] <Skyler_> BBB: by the way you can steal any of my ideas to stuff into your patches if you'd like, I don't care about credit (e.g. the cache thing) [19:06] <j-b> llogan: tell me if it does not work [19:13] <llogan> j-b: looks good to me [19:53] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:e93674c4a322: doc/APIchanges: fill in FFmpeg hashes & versions [20:32] <cone-890> ffmpeg.git 03Anton Khirnov 07master:394fb56c29ee: lavf: always unref the packet passed to av_interleaved_write_frame() on error [20:32] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:8560fdc45195: Merge commit '394fb56c29eee7f4f8f0334d8b5d30d3c54ac703' [20:32] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:3868e97c6b68: ffmpeg: fix vstats [20:41] <cone-890> ffmpeg.git 03Anton Khirnov 07master:e1218ce9149a: rpza: switch to bytestream2 [20:41] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:8b0befe45195: Merge commit 'e1218ce9149aad0ae9770a32a78d77ad2210bd64' [20:46] <cone-890> ffmpeg.git 03Anton Khirnov 07master:c7769df178fd: rpza: use fixed-width int types [20:46] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:0a4311dee55b: Merge commit 'c7769df178fd670156f1c11f6c8410ddd59bbfee' [21:02] <cone-890> ffmpeg.git 03Anton Khirnov 07master:a46dc49744bd: rpza: move some variables to the blocks where they are used [21:02] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:996fdca8fbc1: Merge commit 'a46dc49744bdc4f2e31725b63ac8e41f701e4fa1' [21:38] <cone-890> ffmpeg.git 03Anton Khirnov 07master:77bb0004bbe1: rpza: limit the number of blocks to the total remaining blocks in the frame [21:38] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:dfc99ca04d76: Merge remote-tracking branch 'qatar/master' [22:04] <cone-890> ffmpeg.git 03Christophe Gisquet 07master:c3390fd56cf5: ra144: use scalarproduct_int16 [22:04] <cone-890> ffmpeg.git 03Michael Niedermayer 07master:8f92edf6f86c: avcodec/ra144: remove redundant AV_ZERO128 [23:01] <michaelni> llogan, theres no link to twitter anywhere on our homepage or am i missing it ? [23:08] <llogan> michaelni: i don't think there was ever a link. [23:08] <michaelni> i think you should add one [23:08] <michaelni> maybe where the g+ and rss icons are there also could be a twitter icon [23:09] <llogan> fine with me. i'll add one in a few days unless you get to it first. [23:10] <michaelni> llogan, this is the correct url ? https://twitter.com/FFmpeg (asking because its one field in the gsoc form) [23:10] <llogan> yes [23:10] <michaelni> thx [23:11] <michaelni> do we have a link to a smaller tan 65x65 logo ? [23:11] <llogan> i'm not sure [23:12] <llogan> what size and logo variant do you need exactly? [23:12] <llogan> square? with or without "FFmpeg"? "3D"? non-3D? [23:16] <michaelni> llogan, "URL to the logo of the organization. Please ensure that the provided image is smaller than 65px65px." [23:16] <llogan> so they can upscale it to 650x650 and print it [23:16] <llogan> i'll send you something [23:46] <michaelni> llogan, i think smaller than 65x65 implies not 65x65 [23:47] <michaelni> also the logo isnt mandatory [23:53] <michaelni> we have no facebook page ? [00:00] --- Tue Feb 11 2014

1 0

ffmpeg.log.20140210
by burek 11 Feb '14

11 Feb '14

[00:45] <roothorick> compiling on Linux amd64, ./configure creates Makefile as a symlink to itself, why? [04:11] <Thraul> Hi I am trying to use ffmpeg to screen my desktop (including system audio) and webcam (with mic) to twitchtv. I have managed to get a "sorta' working script working but the camera overlay stops due to buffering errors. I am Running Arch Linux. My Script is here - http://pastebin.com/4bufxbmf Command Out and Errors Here - http://pastebin.com/zmRNpuFz any help appreciated. [04:25] <llogan> Thraul: ffmpeg -f x11grab -video_size 1600x900 -framerate 30 -i :0.0 -f v4l2 -video_size 240x120 -framerate 30 -i /dev/video0 -f alsa -ac 2 -i plughw:0,0 -filter_complex "[0:v]scale=1024:-1,setpts=PTS-STARTPTS[bg];[1:v]setpts=PTS-STARTPTS[fg];[bg][fg]overlay=10:H-h-10,format=yuv420p[out]" -map "[out]" -map 2:a -vcodec libx264 -maxrate 3000k -bufsize 4000k -acodec libmp3lame -ar 44100 -b:a 128k -f flv [04:25] <llogan> output [04:30] <Thraul> thanks llogan no buffer error messages :D no dropped frames [04:30] <Thraul> sweet [04:31] <llogan> Thraul: where did you find that script? [04:33] <Thraul> I slapped it together using different scripts I found online. The streaming part worked then found the part about -vf too add a camera to the stream so added it [04:33] <llogan> i should finish that twitch guide... [04:34] <llogan> i'll be saying that for 6 months [04:35] <Thraul> haha [04:35] <Thraul> camera webcam overlay a little bg trying to reduce it [04:38] <Thraul> i tried cutting the -video_size 240x120 in half to 120x60 but camera image still the same size :( [04:39] <llogan> Thraul: you have to see what sizes your webcam supports. [04:39] <llogan> then you can use the size it provides instead of scaling it [04:39] <llogan> i forgot to add "-g 2" for your command as an output option [04:40] <Thraul> the camera is fine just twice the size of what I want lol [04:41] <Thraul> where add -g 2? before filter_complex? [04:41] <llogan> ffmpeg -f v4l2 -list_formats all -i /dev/video0 [04:42] <Thraul> [video4linux2,v4l2 @ 0x1738040] Raw : yuyv422 : YUV 4:2:2 (YUYV) : 640x360 320x240 640x480 960x720 1280x720 [video4linux2,v4l2 @ 0x1738040] Compressed: mjpeg : MJPEG : 640x360 320x240 640x480 960x720 1280x720 [04:42] <llogan> i'd put it after bufsize for OCD-ness. i like to group options by video, audio, etc. [04:43] <llogan> don't webcams ouput small sizes anymore? [04:44] <Thraul> *shrugs* nfi [04:45] <Thraul> i am also going to push it and say I want a png file to added above the webcam when we get the scale size right :D thanks llogan for the help [04:45] <llogan> add "-input_format yuyv422" as an input option for your webcam for the big encoding example, then change -video_size to 320x240 [04:45] <llogan> then use "[1:v]scale=120:-1,setpts=PTS-STARTPTS[fg]" [04:46] <llogan> are you using ffmpeg from Extra? [04:47] <Thraul> "[0:v]scale=1024:-1,setpts=PTS-STARTPTS[bg];[1:v]setpts=PTS-STARTPTS[fg];[bg][fg]overlay=10:H-h-10,format=yuv420p[out]" so this whole line changes? [04:47] <Thraul> [moe@marvin ~]$ yaourt -Q ffmpeg extra/ffmpeg 1:2.1.3-1 [04:47] <llogan> you just want to add the scale for the webcam, so the whole filtergraph will look like: "[0:v]scale=1024:-1,setpts=PTS-STARTPTS[bg];[1:v]scale=120:-1,setpts=PTS-STARTPTS[fg];[bg][fg]overlay=10:H-h-10,format=yuv420p[out]" [04:48] <llogan> Arch does a good job at keeping up and doesn't need no stinkin' forks. [04:51] <Thraul> thats why i moved from debian to arch to get the upto date and working packages apps lol plus "it works" [04:51] <llogan> a move that i approve of. anyway, for the logo just add "-i logo.png" or whatever, and then use another overlay filter to place it where you want. [04:53] <Thraul> ok just tried script again with the new filter you gave me and now getting Option input_format not found. [04:53] <llogan> you can, of course, omit your API key [04:54] <Thraul> command and output http://pastebin.com/5NLEBMvY [04:55] <llogan> you've placed it as an input option for your alsa device. [04:56] <Thraul> ok moved it to correct place [04:56] <llogan> my webcam seems to freeze when using "-input_format yuyv422". so you may just remove it anyway. [04:57] <llogan> oh, mine chooses rawvideo by default instead of mjpeg like i thought it would. i never use these things... [04:59] <Thraul> bingo thats brilliant [05:02] <Thraul> ok now just need to install pulseaudio and get that working instead of mucking around and getting alsa to working and audio should be good to go :D [05:02] <llogan> with the logo: http://pastebin.com/QXLSiGMk [05:02] <llogan> also see http://ffmpeg.org/ffmpeg-devices.html#pulse-1 [05:04] <Thraul> yeah -f alsa -i pulse :D [05:04] <llogan> -f pulse -i default [05:04] <Thraul> oh okies [05:05] <llogan> see the pulse docs. [05:05] <llogan> i've got to go now. [05:06] <Thraul> thanks for help llogan will try the audio and stuff later will let you know how i go. thanks for the help [08:51] <icedwater> Hi, I understand it's possible to record your desktop using avconv -f alsa -i hw:0,0 -f x11grab -r 15 -s $(xwininfo -root | grep geometry | awk {print $2;}) -i :0.0 -acodec wmav1 -vcodec flv -b:v 16384k output.avi. However, I haven't been able to find the right audio card, is there anyone who has done similar? [10:01] <relaxed> icedwater: did you look at https://trac.ffmpeg.org/wiki/Capturing%20audio%20with%20FFmpeg%20and%20ALSA ? [10:10] <icedwater> Thanks relaxed, checking with arecord -L now. [10:12] <sacarasc> Also, avconv is from a different project to FFmpeg, you should go to #libav for help with it. [10:12] <relaxed> icedwater: however, that guide still applies to avconv [10:14] Action: icedwater nods. [11:10] <lkiesow> Hey, I've got a question about the blend filter. If I do something like this: [11:10] <lkiesow> ffmpeg -y -i in.mp4 -i in.mp4 -filter_complex:v '[0:v][1:v] blend=all_expr=0' out.mp4 [11:10] <lkiesow> it will give me a completely green video. Now here are the questions: Why green? How do I get a black image instead? [11:11] <lkiesow> Of couse, normally the expression for the blend filter is a bit more complicated, but the basic question is the same [15:48] <sspiff> I'm trying to parse images from AVSubtitleRect's and it works fine on little-endian machines, but it swaps bytes according to a 16bit access pattern on big endian machines. [15:48] <sspiff> is AVSubtitleRect.pict.data[1] something that should be considered private? [15:49] <sspiff> is there a better way to read out the data from a subtitle than reading the AVPicture's manually? [15:49] <sspiff> or is this a bug? [15:53] <sspiff> the RGBA macro in dvbsubdec.c seems wrong - first in that it generates ARGB, not RGBA, and second in that it doesn't care for endianness at all... [17:33] <angelosalatino> Good Morning to everyone [17:33] <angelosalatino> May I ask for some help? [17:36] <klaxa> don't ask to ask, just ask [17:37] <angelosalatino> I don't if what I want to do is possible. I'm trying to play (with) ffplay everything is available on my microphone. But when I try to use this command "ffplay -f alsa -i hw:2,0", an error comes out: cannot set channel count to 2 (Invalid argument) [17:37] <angelosalatino> What I'm looking for is a correct flag to set to 1 channel the input. [17:38] <lkiesow> Try -ac 1 [17:41] <angelosalatino> @lkiesow like this: ffplay -f alsa -i hw:2,0 "-ac 1" ?? it doesn't work [17:41] <klaxa> try: ffplay -f alsa -ac 1 -i hw:2,0 [17:43] <angelosalatino> @klaxa it doesn't work. In fact "-ac" is not a flag for ffplay. [17:43] <klaxa> what version of ffmpeg/ffplay are you using? [17:45] <angelosalatino> @klaxa ffplay version git-2013-12-18-aeccb52 [17:45] <klaxa> can you pastebin your complete input and output? [17:45] <angelosalatino> ok [17:47] <angelosalatino> here you are: http://pastebin.com/LesbegUe [17:49] <klaxa> i don't know enough about alsa, on my machine it works when i select hw:0 instead of hw:0,2 but that might be completely unrelated [17:50] <klaxa> what does aplay -L list? can you pastebin that too? [17:53] <angelosalatino> @klaxa here you are: http://pastebin.com/Gf92jN06 [17:54] <angelosalatino> I choice hw:2,0 because it corresponds to the microphone of my webcam. If I acquire with ffmpeg using that device, it actually records. [17:55] <klaxa> can you pastebin a ffmpeg example that works with that device? [17:58] <angelosalatino> @klaxa http://pastebin.com/5CTJPL1M [18:03] <klaxa> oh can you pastebin arecord -l? [18:03] <klaxa> that will list all devices that can capture audio, maybe there's something useful in there [18:04] <angelosalatino> Yes, I know... [18:05] <angelosalatino> http://pastebin.com/2Fpi7J3a [18:05] <klaxa> that is weird... well you *could* use pulse instead of alsa [18:06] <klaxa> that will add the pulseaudio overhead though [18:06] <klaxa> maybe if you're lucky someone with more alsa knowledge than me reads this [18:08] <angelosalatino> a command like this: "ffplay -f pulse -i hw:2,0" ? [18:08] <klaxa> ffplay -f alsa -i pulse [18:09] <angelosalatino> it works... [18:22] <dannyzb> Would it make sense to place a GPU on a server to convert both on the GPU and the CPU ? [19:32] <excalibr> Is it something to be expected that your mkv file would have problem with audio if the original video that you use to mux into mkv has variable bitrate audio? [19:33] <excalibr> i used -c copy when muxing the vid [19:46] <excalibr> llogan, ffmpeg -i vidfile.mp4 -map 0:v,:0 -map:a,:1 -c copy vidfile.mkv [19:48] <llogan> please re-read what fflogger stated [19:48] <excalibr> well a sec. that needs recreating the mkv to get the output [19:49] <llogan> you can use the -t option to limit the duration if a short output can also duplicate whatever issue you're experiencing [19:53] <excalibr> llogan, http://pastebin.com/raw.php?i=tsQKse3S [19:56] <llogan> excalibr: what's wrong with the output, exactly? [19:59] <excalibr> llogan, random pause and jump then sometimes player timeslider shows incorrect time [19:59] <excalibr> that's on computer. and on tv mediaplayer it complains about wrong audio codec [20:32] <shadowing> would anyone happen to know why encoding an audio file would result in a shorter duration than the raw? [20:34] <ChocolateArmpits> shadowing, did you set your audio rate ? [20:37] <ChocolateArmpits> Is it possible to have several concurent multipass encodes done without setting passlogfile or changing directories ? [20:38] <ChocolateArmpits> concurrent* [20:42] <shadowing> ChocolateArmpits: that's one possibility [20:43] <shadowing> I'm not too sure what I should set my audio rate to be in line with the original raw [20:43] <ChocolateArmpits> What is your audio source? [20:45] <shadowing> it's an aac-encoded ts file [20:45] <shadowing> I'm trying to do a 1 to 1 transcode of a video + audio ts [20:45] <shadowing> except whenever I do it, the video is fine, but the audio is off [20:46] <shadowing> I've been trying to fix it by demuxing the video and audio [20:46] <shadowing> transcode both [20:46] <shadowing> then remux them [20:46] <shadowing> not entirely working though :/ [20:46] <ChocolateArmpits> Do you have audacity or mediainfo to check sample rate ? [20:47] <ChocolateArmpits> Or even ffplay [20:47] <ChocolateArmpits> It should show the sample rate for your file [20:47] <shadowing> yeah I have mediainfo [20:47] <shadowing> but it doesn't really tell me the sample rate [20:47] <shadowing> oh well it does [20:47] <shadowing> 44100 [20:47] <ChocolateArmpits> The in encoding parameters set "-ar 44100" [20:48] <ChocolateArmpits> It should then give correct length [20:48] <ChocolateArmpits> then* [20:50] <shadowing> let me try that out [20:50] <shadowing> any other possible routes I should explore if that doesn't pan out? [20:52] <ChocolateArmpits> Only hard set file limits, like wav not supporting more than about 6 hours of stereo pcm recording [20:52] <ChocolateArmpits> Don't know of anything else to be honest [21:00] <shadowing> mm& I tried setting the audio rate [21:00] <shadowing> so the way I'm testing out whether or not it's working [21:00] <shadowing> is by first transcoding each individual ts segment [21:00] <shadowing> than concatenating them together [21:00] <shadowing> and playing the whole file [21:01] <shadowing> there's still a definite audio gap at the segment boundary [21:11] <shadowing> yeah.. it's still weird [21:11] <shadowing> mediainfo reports the raw duration to be 5s 15ms, but the encoded one is 4s 497ms [21:11] <shadowing> *969ms [22:31] <fazer_> hello! i have MOV file without moov atom, but with full data in mdat. so there are video and audio in s8 44800, how to determine what video codec is in use? [22:32] <fazer_> http://rghost.ru/52344212 - here is a sample, 2MB [22:43] <Paranoialmaniac> i think it is too difficult to get what codecs are used if the file has no moov atom and does not start from a video chunk [22:44] <fazer_> i think that it is h264 AVC 4:2:0 [22:45] <fazer_> it must be some variation of this codec, but i don't know how to extract it properly [22:45] <fazer_> it is corrupted file from cannon 5d mk2 camera. [22:45] <fazer_> but it differs significantly of working MOV files [22:46] <fazer_> however, soundtrack format is fully identical. i already implemented sound extractor [22:47] <fazer_> very intetesting, file share identified this file [22:49] <fazer_> but it's not correct [00:00] --- Tue Feb 11 2014

1 0

ffmpeg-devel.log.20140209
by burek 10 Feb '14

10 Feb '14

[00:01] <BtbN> what, according to the debugger, the avctx pointer to my encoder init function is null oO [00:02] <nevcairiel> dont trust the debugger too much, you're debugging optimized code afterall [00:02] <BtbN> isn't the ffmpeg_g.exe unoptimized for debugging? [00:02] <nevcairiel> its just un-stripped, still optimized [00:02] <BtbN> hm, that complicates things [00:02] <cone-897> ffmpeg.git 03Maxim Poliakovski 07master:cb2162adba40: g2meet: Rename FRAME_INFO to more appropriate DISPLAY_INFO [00:02] <cone-897> ffmpeg.git 03Maxim Poliakovski 07master:3f826039ddcc: g2meet: factor out chunk seeking [00:02] <cone-897> ffmpeg.git 03Maxim Poliakovski 07master:ae95b2f8103c: g2meet: Validate bpp and bitmasks in the display info [00:03] <nevcairiel> in msvc i would just disable optimizations for the files i'm working on with a compiler pragma [00:03] <Compn> you can disable optimizations BtbN [00:03] <BtbN> oh, it's even a configure option [00:04] <BtbN> i started searching for the compiler flags [00:04] <Compn> ehe :) [00:04] <BtbN> i hope it works for msvc [00:04] <Compn> ffmpeg has it because it has to independently test c-code vs cpu optimized code vs asm code .... [00:05] <Compn> or something like that [00:05] <BtbN> i get a random segfault, after 100 lines which also access the avctx variable, and it tells me it's null [00:05] <BtbN> doesn't realy make sense, so i guess it's just optimized out [00:06] <Compn> the fun begins when it doesnt crash after you disable optimizations :) [00:06] <BtbN> i coded a 700 line hardware encoder without running it once, there are hopefully a few obvious things i missed [00:07] <JEEB> the most scary part is when something Just Works [00:07] <JEEB> like my wrapper for the MS IStream interface [00:07] <iive> BtbN: it might be memory overwrite/overflow. using stack protector and/or valgrind could help (if you run linux) [00:07] <BtbN> only msvc currently [00:07] <ubitux> also make sure you have an avclass in your local context struct if you're using avoptions [00:07] <JEEB> yeah, windows doesn't exactly have valgrind-likes :s [00:07] <JEEB> I hate that [00:07] <ubitux> (common mistake...) [00:08] <nevcairiel> you cannot turn off optimizations globally with msvc [00:08] <BtbN> ubitux, AVClass or AVClass* as first member? [00:08] <ubitux> AVClass* yes [00:08] <BtbN> yeah, that's present [00:08] <nevcairiel> add Ž#pragma optimize("", off)Ž on top of your file and enjoy more useful code [00:08] <BtbN> omg [00:08] <nevcairiel> remove when done [00:16] <BtbN> yay, it's no longer null [00:30] <BtbN> seems like the nvenc devs never tested the IYUV input format [00:30] <BtbN> it just randomly crashes from inside of a cuda dll if I just select that format [00:30] <BtbN> selecting YV12 or NV12 works [00:30] <BtbN> so just swapping the two planes it is [00:33] <BtbN> hm, YV12 also crashes [00:34] <nevcairiel> NV12 is typically the preferred hardware format, but its not a format very commonly used in ffmpeg tbh [00:34] <BtbN> well, it offers support for YV12 and IYUV(==I420, the format ffmpeg uses) [00:34] <BtbN> but it just crashes [00:36] <BtbN> hm, no, it doesn't the api supports it, but not this specific implementation [00:36] <BtbN> is there a way to set the pix_fmts of my AVCodec at runtime? [00:44] <BtbN> hm, great. It needs an open encoder session to query the available formats [00:44] <BtbN> which in turn needs an open cuda context [01:34] <michaelni> ubitux, do you want to review a ffprobe patch (Re: [FFmpeg-devel] [PATCH] mjpegdec: parse JPS extension and save relevant stereo3d information) [01:34] <michaelni> ? [01:38] <ubitux> michaelni: only if you insist... [01:38] <ubitux> i have no clue about mjpeg/jps/stereo3d :p [01:39] <michaelni> ok, should i ask saste or do it myslef ? [01:39] <michaelni> iam not really ffprobe maintainer [01:39] <ubitux> ah, sure ask saste ;) [01:40] <ubitux> BBB: uploaded fuzzed11.ivf ;) [01:40] <BBB> argh [01:41] <BBB> thread-only? [01:41] <BBB> -threads 1 is clean here [01:41] <ubitux> it seems [01:41] <ubitux> and not that easy to trigger [01:41] <BBB> so is -threads 2 [01:41] <ubitux> http://pastie.org/pastes/8713321/text [01:42] <Compn> Gravity (2013).1080p.x265.mkv [01:42] <Compn> 1080 hevc ? [01:42] <BBB> what's line 1304 again? [01:42] <Compn> how is hevc decoding times compared to h264 ? [01:42] <BBB> Compn: pretty awful [01:42] <smarter> slow :] [01:42] <smarter> multithreaded, but no asm yet (it's coming) [01:42] <ubitux> BBB: pred = FFMIN(pred, refsegmap[(y + row) * 8 * s->sb_cols + x + col]); [01:43] <BBB> hm... [01:43] <JEEB> Compn, I hope that's done with --preset placebo + maxed out bframes and refs [01:43] <BBB> and that's with my patch? [01:43] <BBB> what threadcount? [01:43] <JEEB> otherwise it's not gonna be better than x264, like, at all [01:43] <BBB> I can't trigger it [01:43] <ubitux> BBB: "auto" :/ [01:43] <ubitux> i'm trying to find an exact value triggering it [01:44] <ubitux> i have 4 core HT ( 8), any idea what value it's picking? [01:44] <BBB> no :- [01:44] <BBB> :-p [01:44] <ubitux> ah, 9 does it [01:44] <BBB> ah yes [01:44] <smarter> JEEB: for the same bitrate? [01:45] <JEEB> smarter, yes [01:46] <JEEB> and if the build is older then even that isn't enough :P [01:46] <smarter> did you test very low bitrates too? [01:46] <JEEB> yes [01:46] <Compn> ubitux : does HT actually act like another core (does it help) , or is it more mystery core (marketing hype) ? [01:46] <ubitux> i see 8 core [01:46] <ubitux> but there are actually only 4 [01:47] <Compn> but is there performance diff using 4 or 8 threads ? [01:47] <ubitux> probably [01:47] <JEEB> smarter, considering that x265 even just some very little time ago could NEVER be considered better than x264 [01:47] <Compn> stupid question from me probably :) [01:47] <smarter> JEEB: that's interesting, I'm doing some x264/vp9 comparaison at low bitrates and as expected h264 falls apart and vp9 stays watchable [01:48] <smarter> JEEB: with preset placebo for x264, and --good --speed 0 for libvpx [01:48] <JEEB> the fact that you can now kind of get some (?) results out of it if you max it out [01:48] <ubitux> --speed 0 unleash the speed with libvpx? [01:48] <JEEB> is kind of great already [01:49] <smarter> ubitux: I meant --good --cpu-used 0 actually [01:49] <smarter> ubitux: which means "slowest setting which is still usable" [01:49] <JEEB> although the lowest I've gone so far is ~415kbps for 720p [01:49] <JEEB> dunno if that is "low enough" for you :) [01:50] <smarter> JEEB: I just encoded the Sintel trailer at 67kbps 480p :) [01:50] <smarter> now doing some 720p [01:50] <JEEB> but x264 was getting a bit derpy at that point already so I would guess the results would be similar with lower rates as well [01:51] <JEEB> http://abload.de/img/matched_visual_opt7ryvz.png http://abload.de/img/checking00173789z9e.png [01:51] <JEEB> you can guess which is which [01:51] <Compn> i liked jasons' ultra low bitrate x264 tests [01:51] <Compn> with low motion video [01:52] <JEEB> Compn, those then later sparked lachs0r's floppy sized tora dora encode [01:52] <JEEB> a full anime episode floppy-sized [01:52] <Compn> lol oh man wheres that ? [01:52] <JEEB> with audio! [01:52] <ubitux> JEEB: watashi, kininarimas'~ [01:52] <Compn> i want to see 1.44mb episode :D [01:53] <JEEB> http://tmp.srsfckn.biz/floppy_tiger.mkv [01:53] <JEEB> 1.28 MB (1,342,980 bytes) not exactly 1.44 [01:53] <ubitux> (http://lucy.pkh.me/kininarimas.webm) [01:54] Action: ubitux runs away [01:54] <Compn> hmm, why cant i play that mkv [01:54] <Compn> wrong colorspace [01:54] <J_Darnley> Dammit FF! I don't want you to play the video! [01:55] <JEEB> ubitux, I love it how that most probably is based on my cap :P [01:55] <JEEB> see the station logo [01:55] <ubitux> JEEB :D [01:55] <ubitux> heh, i have no audio with ffplay on floppy_tiger.mkv [01:56] <ubitux> but i do with mpv [01:56] <Compn> you are missing speex decoder [01:56] <ubitux> oh we don't have a native decoder [01:56] <ubitux> sadness [01:56] <Compn> shhhh , someone will hear you and decide to code one up [01:57] <Compn> also i am dissapoint at the quality of that encode [01:57] <Compn> i'm not sure what i was expecting [01:57] <JEEB> :D [01:57] <Compn> i guess more. [01:57] <JEEB> b-b-but it fits on a floppy! [01:57] <ubitux> vf_pp to the rescue [01:57] <JEEB> :D [01:58] <J_Darnley> What did I expect?! [01:58] <J_Darnley> That is the second worst video I've ever seen [01:58] <JEEB> :D [01:58] <JEEB> I guess I could encoding something like that with any of the new formats [01:58] <JEEB> *could try [01:58] <ubitux> it's missing subtitles :( [01:59] <JEEB> ubitux, I bet those could actually fit [01:59] <JEEB> since it's under 1.44MB by itself [01:59] <J_Darnley> They'd probably fill those remaining KB [01:59] <Compn> nut would have less container overhead? :P [01:59] <ubitux> JEEB: i want them hardsubbed [01:59] <Compn> it has to be 480p too [01:59] Action: J_Darnley goes back to testing [02:00] <ubitux> hey wait there is actually the full episode [02:00] <ubitux> that's pretty impressive by itself [02:00] <JEEB> yup [02:00] <JEEB> only OPED are missing [02:03] <J_Darnley> Dammit cygwin! Stop dieing every time you fork! [02:10] <ubitux> BBB: the code is much more resistant to fuzzing since your latest patch :) [02:10] <ubitux> i think i'll stop fuzzing after the next one [02:13] <ubitux> BBB: ah btw, with assert-level, Assertion pred < 8 failed at /home/ubitux/src/ffmpeg/libavcodec/vp9.c:1305 [02:13] <ubitux> assert-level=2* [02:20] <ubitux> (1 should be enough) [02:24] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:f90a4bfc43c9: mlpdec: fix request_channel_layout behavior. [02:24] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:73be2ebe96ee: Merge commit 'f90a4bfc43c9192e89d9b4c81d80789cd9b38a2f' [02:47] <BtbN> http://bpaste.net/show/lOvUv58DFdyrNBaXBs3s/ Why is it complaining about the pts beeing less than the dts? [02:48] <BBB> ubitux: fixed differently [02:49] <BBB> ubitux: new patch to fix both fuzzed10 and fuzzed11 (it's the same bug essentially) [03:01] <cone-897> ffmpeg.git 03Tim Walker 07master:c1e7de8f62c7: mlp_parser: fix request_channel_layout behavior. [03:01] <BtbN> hm, just adding an offset to the pts seems to work. [03:01] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:4040b56f5afd: Merge remote-tracking branch 'qatar/master' [03:01] <BtbN> But no idea if it's the right solution [03:03] <BBB> BtbN: [nvenc @ 0000004E5C0ED020] Wrote B frame with pts: 1, dts: 2 [03:03] <BBB> BtbN: 1 < 2 that's why [03:04] <BtbN> yeah, but shouldn't that be ok? [03:04] <BBB> the order should be (for input 0, 1, 2, 3; in order of pts; dts): 0, 0; 3, 1; 1, 1; 2, 2 [03:04] <BBB> so you see the dts actually repeats, which is fine [03:05] <BBB> like I said, dts will be min(pts, remaining_input_ts[@]) [03:06] <BBB> so dts can never be greater than pts [03:06] <BBB> dts is always min of all following (including this one) pts, ever [03:07] <BtbN> hm, no. It doesn't like the dts repeating [03:07] <BtbN> [mp4 @ 0000001B601DB240] Non-monotonous DTS in output stream 0:0; previous: 201472, current: 201472; changing to 201473. This may result in incorrect timestamps in the output file. [03:09] <BBB> michaelni: ^^ ? [03:10] <BBB> timestamps give me the creeps [03:11] <BtbN> just substracing the number of B frames from the dts works. But doesn't seem like the right solution [03:23] <michaelni> BtbN, does it work if you dont set the dts ? [03:25] <BtbN> michaelni, so, allways setting it to 0? [03:25] <michaelni> AV_NOPTS_VALUE [03:25] <michaelni> and if that doesnt work you can calculate them, they are basically sorted pts more or less [03:26] <BtbN> yeah, sorting them is what i did before, it didn't work because some of them ended up beeing <pts [03:26] <BtbN> Setting it to NOPTS_VALUE leads to [mp4 @ 00000027A29B5580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 768 >= 256 [03:27] <michaelni> BtbN, you must set has_b_frames to the reorder buffer size [03:28] <michaelni> its 1 for mpeg2 style bframes and 2 for that 1 level b pyramid thing [03:28] <BtbN> does the dts allways increse by 1 each frame? [03:30] <michaelni> if your material is constant fps with no droped frames then yes for mpeg1/2/mpeg4-asp dts, iam not 100% about h264 they possibly allow funky things [03:30] <michaelni> but dont waste your time on "funky things" thats probably not relevsant here [03:31] <BtbN> yeah, just substracing the number of B frames from the dts makes it work [03:31] <michaelni> its wrong though if fps isnt constant [03:33] <michaelni> did you try dts == NOPTS_VALUE with correctly set has_b_frames ? [03:33] <BtbN> not yet [03:36] <BtbN> yes, seems to work [03:39] <BtbN> Now i have to find out why it uses 80% CPU power while only doing 200 fps [03:45] <BtbN> the encoder works fine now, hm [03:45] <BtbN> but it is way too slow [03:45] <BtbN> and uses way too much cpu [04:14] <lukaszmluki> can someone give a hint where to find conversion yuv420p->yuv444p12le? [04:37] <BtbN> Is it possible to tell ffmpeg to put the decoder and encoder into seperate threads? [05:12] <andrewrk> BtbN, you mean with the ffmpeg command? [05:13] <BtbN> yeah [05:13] <andrewrk> I think you would have to write your own code [05:14] <andrewrk> pardon my self-promoting here but... I have a library that sits on top of ffmpeg and provides encoding with a separate thread for decoding and encoding. [05:14] <andrewrk> https://github.com/andrewrk/libgroove [05:14] <andrewrk> may or may not be of use to you [05:14] <BtbN> hm, cause it currently seems like the decoder is using up most of the performance [05:15] <BtbN> and as the nvenc encoder isn't multithreaded, it's quite limited by that [05:16] <BtbN> i'd have to get libx264 support in there, so i can compare it [05:17] <andrewrk> oh don't look at the thing I linked you then. it's audio only [05:22] <BtbN> 60% of the time is spent in [05:22] <BtbN> decode_slice in h264.c. The other 40% is spent in memcpy. [12:49] <michaelni> BtbN, some decoders and some encoders use multiple threads [13:01] <michaelni> i havnt really looked at your code at all but if its slower than expected first i would make sure the encoder has enough frames so it has something to work with and isnt limited to encoding one frame during the time the wraper executes on the cpu [13:22] <BBB> ubitux: wanna review latest round of patches on ML? Also see github (https://github.com/rbultje/ffmpeg/commits/vp9-context-opts) [13:22] <BBB> ubitux: github has one further patch that helps simd somewhat [13:23] <ubitux> yes i had a quick look and it looked nice [13:23] <BBB> \o/ [13:23] <BBB> no more fuzz issues? [13:23] <BBB> (after that last patch) [13:24] <ubitux> so far, no, but i stopped [13:24] <ubitux> i'll make a new run after this patchset [13:24] <ubitux> and i guess we should be done with it [13:24] <BBB> maybe I should email that google guy and ask him to do some cluster fuzzing [13:24] <ubitux> that's what i was going to suggest [13:24] <ubitux> :D [13:24] <BBB> lol [13:24] <BBB> we also still do need intra pred assembly [13:24] <BBB> and prefetch [13:25] <ubitux> i won't have much free time in the following weeks to work on vp9 [13:25] <ubitux> but i'll at least do a benchmark when i'll get my avx2 hw [13:26] <ubitux> if it's faster than libvpx even without avx, i guess we could start publishing the bench [13:26] <ubitux> otherwise... i'll try to write some asap :p [13:32] <Skyler_> FYI you can use the Intel SDE to write avx2 even without an avx2 CPU [13:33] <Skyler_> it's not perfect since you can't, like, actually benchmark it, but it lets you get quite a bit done at least [13:34] <burek> trac still doesn't work? :( [13:34] <Skyler_> great if you're terribly impatient about asm ;) [13:36] <burek> is there any help needed to get the trac up and running again? [13:36] <ubitux> Skyler_: good to know, but i think i'll just wait a little :) [13:38] <BBB> Skyler_: it's much more fun if you can see the results [13:44] <Skyler_> true, true! [13:46] <BBB> and latest mbps have haswell from what I gather, so maybe I should upgrad [14:06] <wm4> someone wants mplayer's vf_tfields, because it's so fast :/ [14:06] <wm4> where did the libmpcodecs filter go? [14:10] <wm4> apparently it was never part of the libavfilter internal libmpcodecs [14:11] <wm4> even though it's in mplayer [14:12] <wm4> user wants a deinterlacer that's faster than yadif [14:13] <wm4> libpostproc's bob deinterlacer is out because it doesn't double the frame rate [14:14] <nevcairiel> use vf_separatefields? :p [14:15] <Daemon404> wm4, anything faster will look pretty back [14:15] <Daemon404> bad* [14:16] <nevcairiel> there is also vf_kerndeint, no idea how it compares in speed/quality [14:16] <wm4> separatefields looks pretty straight-forward [14:16] <nevcairiel> it'll have severe bobbing though [14:17] <wm4> oh, separatefields doesn't fill the missing lines [14:17] <wm4> so it's half-res [14:17] <nevcairiel> easy enough to add a scale filter [14:18] <BBB> then it loses it's fast [14:18] <nevcairiel> in point scaling mode? :D [14:18] <BBB> speaking of awful [14:19] <wm4> here's an evil idea: use separatefields and adjust the PAR to double the pixel height, let the video driver do the rest [14:19] <nevcairiel> cant you let the video driver deinterlace in the first place [14:19] <wm4> apparently this isn't possible in this case [14:30] <J_Darnley> Uhh... separating fields with a dumb resize will produce horrible bobbing. [14:31] <nevcairiel> he asked for fast, not pretty [14:31] <wm4> well, I'm not sure what the user actually wants [14:31] <kierank> wm4: use yadif with some of the speedups [14:31] <wm4> which speedups? [14:32] <nevcairiel> ignore spatial checks or what its called [14:32] <kierank> yeah [14:32] <nevcairiel> or just output 1 frame per two fields :p [14:32] <wm4> nah, user wants 1 frame per field for some reason [14:32] <nevcairiel> hand him a C compiler [14:33] <kierank> wm4: that "some reason" is know as proper deinterlacing [14:33] <wm4> he has one, and he made a patch to add yucky mplayer code (vf_tfields) back to my code [14:33] <kierank> with correct temporal resolution [14:33] <wm4> what does temporal resolution matter if it looks like crap anyway? [14:34] <iive> wasn't there an idea for crt like deinterlace? aka separate the fields into frames, but don't bother with filling the gaps and keep them black [14:34] <iive> let the human eye, LCD latency fill the gaps. [14:35] <nevcairiel> that might work if you output unscaled, if you start scaling afterwards it will probably result in terrible artifacts [14:35] <iive> you should just use interlaced scalling. [14:35] <nevcairiel> not sure the pesistence of vision is strong enough for that to work [14:35] <iive> and encode the result as interlaced too. [14:45] Action: J_Darnley should test that in avisynth [14:51] <Daemon404> vlc clones at 90 mbit/s... nice [14:52] <wm4> btw. what's the deal with git://source.ffmpeg.org/ffmpeg.git [14:52] <wm4> it's so slow [14:52] <wm4> is it different from the videolan repo? [14:52] <Daemon404> i dont know [14:53] <ubitux> wm4: no it's the same [14:53] <ubitux> afaik [14:54] <Daemon404> Receiving objects: 32% (135317/419525), 83.57 MiB | 10.04 MiB/s [14:54] <Daemon404> not ffmpeg, but i get the same for ffmpeg [15:04] <burek> is there any info about trac? [15:04] <burek> what's going on and when (if) is it gonna be up again? [15:07] <kierank> wm4: try watching sports [15:08] <kierank> better to see some quality issues than to get a headache [15:08] <kierank> J_Darnley: vlc has a "deinterlacer" that simulates persistence of vision [15:13] <Daemon404> michaelni, ping [15:16] <michaelni> Daemon404, source.ffmpeg.org is videolan [15:16] <Daemon404> nah thats not why im pinging you [15:16] <Daemon404> do you mind if i push the raw hevc demuxer patch to ffmpeg (you looked at it months ago) [15:17] <Daemon404> its just registering it in rawdec.c and pals [15:17] <michaelni> sounds harmless [15:17] <Daemon404> ok :) [15:17] <Daemon404> im preparing to revive my x265 patch [15:18] <michaelni> cool [15:18] <Daemon404> now that its semi-ok [15:19] <smarter> what about kvazaar? :) [15:19] <Daemon404> its not useful yet [15:19] <JEEB> kvazaar needs clean-up [15:19] <Daemon404> x265 is actually outperforming x264 in some respects now [15:20] <Daemon404> at least on some limited testing [15:20] <Daemon404> i dont think kvazaar has a real API yet either? [15:20] <JEEB> after kvazaar gets all of the encoder internals out of main() and an actual API a patch can be made for it [15:20] <JEEB> yeah [15:21] <BBB> lol x265 [15:21] <BBB> and people complain about google being corporate [15:21] <BBB> "stop using my original, self-devised, trademarked(sic) name or we'll sue you" [15:22] <Daemon404> BBB, they got the rights from x264/json [15:22] <JEEB> yeah, I think MCW is on the level of google or worse with regards to community'ing, and of course the PR person has to make it even harder for it to get into it [15:23] <Daemon404> jason* [15:29] <cone-814> ffmpeg.git 03Derek Buitenhuis 07master:ef5d32b9c531: Add raw HEVC muxer [15:35] <Daemon404> nevcairiel, i see vlc has a hardcoded check for your toolchain [15:35] <Daemon404> with your name and all [15:35] <nevcairiel> really, what for [15:35] <Daemon404> i dont know [15:35] <Daemon404> but it does. [15:35] <nevcairiel> its not like it has any special patches [15:36] <Daemon404> i know [15:36] <JEEB> I remember bringing it up on #videolan as a simple thing to use for a win32 mingw-w64 toolchain [15:36] <JEEB> so it probably goes back to that [15:36] <Daemon404> oic [15:36] <nevcairiel> link? :p [15:36] Action: Daemon404 still uses his own :P [15:37] <nevcairiel> that reminds me that i wanted to build a new one with the mingw-w64 3.1 release, but i looked it up and most changes are only in their broken winpthreads thing which i dont build anyway =P [15:38] <Daemon404> wait it might be in msys O.o [15:38] <Daemon404> its in /!components.txt [15:38] <Daemon404> whatever that is [15:38] <nevcairiel> oh [15:38] <nevcairiel> thats just Xs package then, he includes that file with all the package versions of msys, and my mingw toolchain [15:38] <Daemon404> im not using his [15:38] <Daemon404> i used mingw-get [15:39] <nevcairiel> weird [15:39] <nevcairiel> never used that [15:39] <nevcairiel> maybe thats why so many people download my package [15:39] <nevcairiel> i always wondered [15:39] <Daemon404> lol [15:39] <nevcairiel> (i analyze apache logs!) [15:41] <nevcairiel> i even got a request to enable fortran in my builds once [15:41] <Daemon404> lol yeah [15:42] <wm4> how broken is this winpthreads thing? [15:42] <JEEB> it is [15:42] <JEEB> it tries to be a higher-level wrapper [15:43] <nevcairiel> havent tried it recently, maybe they fixed the worse things, but it used to just crash and if it didnt have terrible performance [15:43] <JEEB> but it ends up just being slow [15:43] <nevcairiel> pthreads-w32 is much better [15:43] <JEEB> yeah, I didn't get the crashes but it was slow as molasses [15:43] <wm4> I looked at its code once, and it seems they have to do half a dozen of low level locks for a simple pthreads lock [15:43] <Daemon404> last thing i tried with winpthreads didnt even build [15:43] <Daemon404> so back to pthreads-win32 it was [15:45] <nevcairiel> I only really use pthreads because of this worker thread in the UDP code, should revive the ML thread to make it more generic [15:46] <nevcairiel> otherwise the win32threads layer in ffmpeg would be enough [15:46] <wm4> doesn't this worker thread thing rely on cancellation? [15:46] <wm4> well, apparently it works anyway [15:47] <nevcairiel> yeah which the native thread API doesn't take too kindly, but pthreads-w32 implemented it somehow [15:51] <Daemon404> jesus [15:51] <Daemon404> running vlc's configure on windows trashed my system [15:51] <Daemon404> i had to hard reboot [15:52] <Daemon404> infinite loop of ./ABOUT-NLS: command not found [15:52] <Daemon404> somehow screwed me [15:52] <wm4> fork bomb on windows? [15:52] <Daemon404> yea [15:53] <nevcairiel> running such configures can be evil, as you can't even simply stop it by closing the console window [15:53] <Daemon404> yep [15:53] <Daemon404> my rdp actually froze [15:53] <nevcairiel> the windows command prompt closes, but it doesnt take the sh with it [15:53] <Daemon404> had to kill it IRL [15:53] <Daemon404> with my hands [15:54] <Daemon404> i wonder why the hell its trying to run a damn text file [15:54] <nevcairiel> all scripts are just text files [15:55] <Daemon404> a text file with english in it [15:55] <Daemon404> maybe vlc doesnt like out of tree builds... [15:58] <Daemon404> it explodes at "checking if dolt supports this host" [16:03] <Daemon404> it's some sort og globbing failure [17:16] <cone-814> ffmpeg.git 03mrlika 07master:36a629795370: avcodec/dvbsubdec: DVB subtitles decoder: support of 5 bytes extradata format [17:16] <cone-814> ffmpeg.git 03Ramiro Polla 07master:5965adeb2047: lavd: add decklink output device [17:24] <kurosu_> regarding the x265 trademark, I've heard that, despite the equivalent of relevant prior art (people having websites or s/w with x265 in the name, related to a h265 encoder), there is a case here of the typical uspto "first to file" case [17:24] <kurosu_> it's even stronger for trademarks, I've been told [17:50] <kierank> kurosu_: it's not as simple because vlc has the trademark in eu and gb [17:50] <kierank> whereas mcw have it in usa [17:50] <kurosu_> for x265 ? [17:50] <kierank> yes [17:51] <kurosu_> I think I've seen mcw ask for it around last summer, right ? it would still be up for dispute, I gues [18:08] <ubitux> BBB: so, you branch is mergeable? [18:09] <BBB> I think sp [18:09] <BBB> o [18:10] <ubitux> gonna do a few test and push [18:10] <BBB> ty [18:10] <BBB> i have 11 simd intra pred funcs to write [18:10] <BBB> almost done [18:13] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:9aeca1c572dc: vp9: just disallow temporal or no-update segmentation on size-change. [18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:cdfcd0612601: vp9: coef context reading optimization. [18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:0c30c8ddc138: vp9: faster skip-block coefficient blanking. [18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:1dc8559e25b4: vp9: more aligned zeroes. [18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:fccd7d81b694: vp9: decode_mode context optimizations. [18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:45245e202ef1: vp9: coef decoding context-splat speedup. [18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:37c6eac296ba: vp9: remove memset in loopfilter level setting loop. [18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:0d4d223353b7: vp9: invert order in l[] intra prediction array. [18:14] <BBB> \o/ [18:14] <BBB> ok [18:16] <BBB> let's finish the intra pred simd, that's the big thing now [18:17] <ubitux> http://pastie.org/pastes/8715662/text [18:17] <ubitux> slowest remaining C func is dc_32x32_c [18:17] <BBB> cool [18:18] <BBB> I have simd for that one already [18:18] <ubitux> :) [18:18] <BBB> feel free to try all sort of weird stuff to make decode_coeffs_b faster [18:18] <BBB> jason's idea was pretty good [18:19] <BBB> i.e. instead of saving N (literal) for context and using N+M+1>>1 as next-coef-context, save 2*N+1 (literal) as context and do N+M>>2 (note the +1 is missing) [18:19] <BBB> the lack of the +1 should help speed (missing inc in each contextualization) [18:20] <BBB> also the division by 2 (for tx32) can be moved outside the decode_coeffs_b calling loop in decode_coeffs [18:20] <kurosu_> if dc_32x32_c is the slowest function, I guess that a good sign :) [18:20] <Skyler_> I'm surprised decode_coeffs uses up so much time (the non-b part), I wonder where that's all going [18:21] <Skyler_> does inlining decode_coeffs_b help? or is it the memsets maybe? I don't have a proper profiler on me at least [18:22] <BBB> I just removed the memsets [18:22] <BBB> they were part, so removing them helped a bit [18:22] <BBB> but there's still a lot of expensive bookkeeping in there [18:22] <BBB> vp9 coef decoding isn't exactly light-weight as it was in vp8 [18:23] <BBB> ubitux: on that sample (etv5k), how much faster are we than libvpx? [18:23] <Skyler_> I wonder if stuff like lines 2058-2065 could be made faster by templating it based on the transform size [18:23] <Skyler_> since you could make the logic more efficient if you knew what etp1d was [18:23] <Skyler_> *step1d [18:23] <ubitux> BBB: can you provide a libvpx cmd line? [18:24] <ubitux> BBB: with & without threading? [18:26] <ubitux> BBB: vpxdec bla.webm -o /dev/null, anything faster? :) [18:27] <wm4> are there actually audio codecs that have "key frames"? this seems to imply yes, but unsupported: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/utils.c;h=c8fd8c6… [18:29] <wm4> or better worded: audio codecs that have non-keyframes [18:29] <BBB> ubitux: ffmpeg -c:v libvpx-vp9 -threads 1 -f null - [18:29] <nevcairiel> truehd/mlp has major sync frames which are required to start decoding [18:29] <ubitux> BBB: mmh, i should probably make a build with a recent libvpx [18:30] <BBB> yes [18:30] <BBB> Skyler_: yeah that was one of my ideas, esp. for the uv (because for e.g. tx32x32, you don't actually need to loop anymore, you can only fit one, thus skipping all loop setup) [18:30] <wm4> there's no mlp encoder I guess [18:31] <BBB> Skyler_: and as I sugested to ubitux before, move division by 2 in decode_coeffs_b out of loop by moving it into the calling branch outside the caller loop in decode_coeffs [18:31] <ubitux> ./ffmpeg -v 0 -nostats -i ~/samples/vp9/etv5k/etv5k.webm -f null - 63.88s user 0.62s system 224% cpu 28.669 total [18:31] <ubitux> ./vpxdec ~/samples/vp9/etv5k/etv5k.webm -o /dev/null 62.14s user 0.36s system 99% cpu 1:02.58 total [18:31] <BBB> like if (tx=32x32) { for .. for .. decode_coeffs_b_32x32 } [18:31] <BBB> ubitux: you're using threading, that's cheating [18:32] <BBB> ubitux: use -threads 1 (and whatever the equivalent in libvpx is) [18:32] <ubitux> BBB: yes, running [18:32] <Skyler_> BBB: I wonder if avoiding that branch is worth the extra code size, I guess test it at least [18:32] <ubitux> BBB: vpxdec is not threaded oO [18:33] <Skyler_> geez, I wonder why they did that though. why couldn't they have just divided qmul by two [18:33] <Skyler_> such a weird choice [18:33] <ubitux> ./ffmpeg -v 0 -nostats -threads 1 -i ~/samples/vp9/etv5k/etv5k.webm -f null - 48.57s user 0.03s system 99% cpu 48.653 total [18:34] <ubitux> ./vpxdec ~/samples/vp9/etv5k/etv5k.webm -t 1 -o /dev/null 62.76s user 0.34s system 99% cpu 1:03.17 total [18:34] <ubitux> (git/master for both) [18:35] <wm4> indeed, truehd mkv files have the key frame flag only set on some packets, but remuxing truehd with ffmpeg sets the flag on every packet :( [18:39] <wm4> well, still better than this lavf muxed mkv sample file I have here that doesn't have the key frame flag set on any packets [18:40] <BBB> ubitux: it is - loopfilter and tile threading [18:40] <BBB> not frame [18:41] <ubitux> ah, k [18:41] <BBB> loopfilter is default, it doesn't help much [18:41] <BBB> like 5% or 10% or so [18:41] <BBB> (after lf simd) [18:41] <ubitux> BBB: Carl spotted compilation problem, i'll fix in a second unless you want to [18:41] <BBB> also their lf is way slower than ours, most of ours acts on 16px at a time (typical sse2 stuff), theirs is mostly 8px at a time [18:41] <BBB> go ahead, I'm not doing anything [18:42] <BBB> actually I'm hungry [18:42] <BBB> anyway 30% faster is pretty good [18:44] <kurosu_> indeed, impressive [18:44] <kurosu_> I've been asked by first-timer at asm how much good asm can bring - I get my reply here [18:45] <cone-814> ffmpeg.git 03Clément BSsch 07master:c333987876ba: vp9: fix compilation with !HAVE_FAST_64BIT. [18:46] <kurosu_> I fear the initial structure is also a key element [18:47] <kurosu_> I fear there may be bottlenecks with the current hevc implementation [18:48] <kurosu_> in particular, last I checked, there was a lot of unnecessary buffering, from those (x, y) addressing to the buffer [18:49] <Daemon404> [17:42] <@BBB> anyway 30% faster is pretty good <-- but isnt it 64-bit only [18:49] <Skyler_> writing 32-bit versions of some of that asm looks very exciting [18:49] <Daemon404> i would have though chrome would be ffvp9's main use case [18:49] <Daemon404> i.e. 32-bit [18:50] <nevcairiel> you dont think google use their own decoder? :p [18:50] <Daemon404> who knows [18:50] <BBB> kurosu_: right, it's both [18:50] <BBB> Daemon404: it's not hard to write 32bit asm [18:50] <BBB> Daemon404: I just don't care [18:51] <BBB> I guess I'm trying to give chrome incentive to switch to 64bit [18:51] <Daemon404> o/ [18:51] <Daemon404> lol yeah right [18:51] <BBB> still being 32bit is about as laughable as the hevc-vp9-x264 comparisons I've seen so far [18:51] <Daemon404> same for steam (which uses chromium) [18:51] <BBB> cargo cult etc. [18:52] <Daemon404> i dont know how many people still run 32bit windows [18:52] <BBB> fuck 'em [18:52] <BBB> tell them to upgrade [18:52] <Daemon404> prett sure a leading browser isnt going to take that stance [18:52] <BBB> why do we all need the newest iphone and samsung galaxy, but a 10year old windows is ok? [18:53] <wm4> because windows is not a status symbol [18:53] <Skyler_> I'm guessing still being 32-bit might have to do with a combination of required libs being 32-bit, 32-bit sandboxing code (segmentation doesn't work in long mode), the JIT, and stuff like that? [18:53] <Daemon404> Skyler_, the JIT works perfectly fine in 64bit [18:53] <Daemon404> thats how node.js uses it. [18:53] <Skyler_> okay so they did at least port that [18:54] <Daemon404> all of chrome woks in 64bit [18:54] <Daemon404> because OS X is 64bit [18:54] <Daemon404> chrome too iirc [18:54] <nevcairiel> they dont want to go full 64-bit yet because all their security testing didnt cover it yet [18:54] <kierank> Daemon404: seems they announce coaches by twitter [18:54] <Daemon404> they == ? [18:54] <kierank> fgw [18:54] <Daemon404> FGW? [18:54] <Daemon404> o ok [18:55] <Daemon404> i have a backup (proper) coach booked [18:55] <Daemon404> i am *not* missing my nyc trip due to england not being able to handle rain, of all things [18:55] <Daemon404> :V [18:55] <nevcairiel> which is kinda amusing, as thats the weather you think about when someone mentions england [18:56] <Daemon404> the irony is lost on a lot of brits i talk to. [18:56] <kierank> Daemon404: to be fair the railway held firm for 160 years [18:56] <kierank> brunel being the great man he is [18:56] <Daemon404> ... it's flooded the last 3 years ive been here [18:56] <Daemon404> ive been trapped every single year [18:56] <Daemon404> due to rain [18:56] <nevcairiel> maybe being 160 years old is the issue at hand? :D [18:56] <kierank> i was trapped last year [18:56] <smarter> chromium in every 64 bits linux distribution is 64 bits, but release a 32 bits and a 64 bits Windows executable is probably confusing for people [18:56] <Daemon404> nevcairiel, poor design choices 160 years ago [18:56] <kierank> well vlc is 32-bit no? [18:57] <Daemon404> kierank, its both now [18:57] <Daemon404> but no win64 ssl [18:57] <Daemon404> because lollicenses [18:57] <nevcairiel> license is different in 64-bit? [18:57] <Daemon404> win64 needs a newer gnutls or whatever [18:57] <Daemon404> which has lgplv3 deps [18:57] <Daemon404> or something [18:57] <Daemon404> gpl fun. [18:58] <kierank> i need to buy food but it's raining :( [18:58] <Daemon404> kierank, the olympics on vt are hilariou [18:58] <kierank> why? [18:58] <Daemon404> brits are losing their shit over a bronze medal win [18:59] <Daemon404> "brits 23rd medal in the winter olympics since 1920" [18:59] <Daemon404> just lol. [18:59] <kierank> we don't have snow you know [18:59] <Daemon404> northern england gets snow usually [18:59] <Daemon404> iirc [18:59] <kierank> not enough to train year round [18:59] <Daemon404> no county does, except maybe russia [19:00] <Daemon404> country* [19:00] Action: Daemon404 dinner & [19:55] <cone-814> ffmpeg.git 03Derek Buitenhuis 07master:722554788b77: Add raw HEVC muxer [19:55] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:ffe987b96dd4: Merge commit '722554788b77c13748e83458f626a9ac38b70072' [19:58] <ubitux> smarter: i don't know if i should laugh or cry reading what you said [19:59] <ubitux> it's certainly true that a huge part of the people downloading chrome wouldn't be able to choose what download button to clic between 32 and 64 bit [20:03] <cone-814> ffmpeg.git 03Maxim Poliakovski 07master:bc3f03567a04: g2meet: rename FRAME_INFO to more appropriate DISPLAY_INFO [20:03] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:5b23c7ed6fa9: Merge commit 'bc3f03567a04a9f7e412bcf2ca09c163f3f13941' [20:03] <JEEB> hmm [20:04] <Daemon404> ubitux, you can discern wordize from the user agent [20:04] <Daemon404> word size* [20:06] <ubitux> sounds like win64 is really fun anyway [20:07] <JEEB> oh, how fun. mp4 has all MPEG-1 audio muxed in the same way so you have parse it [20:08] <kierank> Daemon404: but it would be a pita to coordinate plugins [20:08] <JEEB> and mp4box loved to break mp3 streams somehow when muxing [20:08] <JEEB> and the broken packet leads to a misparse as mp1 [20:09] <Daemon404> gpac? break stuff? [20:09] <Daemon404> NO WAY [20:09] <Daemon404> never. [20:10] <JEEB> inorite [20:10] <JEEB> http://fushizen.eu/samples/mp3_parsed_as_mp1.mp4 [20:10] <Daemon404> mp1? ive never seen that in the wild even... [20:10] <BtbN> How do i tell the configure script where to look for libx264 libs and headers? [20:11] <JEEB> --extra-cflags="-I/your/prefix/include" --extra-ldflags="-L/your/prefix/lib" [20:11] <Daemon404> no! [20:11] <Daemon404> no no no ! [20:11] <Daemon404> use pkg-config properly. [20:11] <JEEB> or you use PKG_CONFIG_PATH [20:11] <BtbN> pkg-config on windows? [20:11] <ubitux> won't work [20:11] <BtbN> with msvc? [20:11] <Daemon404> BtbN, yes [20:11] <Daemon404> ah msvc [20:11] <ubitux> we're not using pkg-config to probe [20:11] <Daemon404> ubitux, oic [20:11] <JEEB> and yeah, pkg-config isn't used for libx264 [20:11] <JEEB> :P [20:11] <ubitux> i sent a patch for using pkg-config [20:12] <ubitux> carl didn't like it much [20:12] <ubitux> i didn't insist [20:12] <Daemon404> imo pkg-config is more correct [20:12] <ubitux> i agree [20:12] <Daemon404> BtbN, you need an msvc-compatible .lib file [20:12] <Daemon404> named x264.lib [20:12] <BtbN> i have that(just built it myself) [20:12] <Daemon404> ah ok [20:12] <Daemon404> then use what JEEB said [20:12] <Daemon404> *or* [20:12] <Daemon404> set %LIB% and %INCLUDE% [20:13] <JEEB> yeah, I think with msvc it's simpler to use the system variables [20:13] <JEEB> I tried to use extra-c/ldflags myself before with msvc [20:13] <Daemon404> its easier to set before launching bash [20:13] <JEEB> gave up [20:13] <JEEB> :V [20:15] <cone-814> ffmpeg.git 03Andrew Kelley 07master:b0c2c097e422: lavf: default .ogg audio to libvorbis if we can [20:15] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:cf0e5b7fd4d1: Merge commit 'b0c2c097e422b9e10a7d856582f8321d28af821e' [20:15] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:28caf13ac394: fate: fix lavf-ogg test [20:18] <BtbN> libx264 is faster than nvenc, but only because it can use all 4 cores [20:18] <Daemon404> im sure it is also significant better quality. [20:18] <Daemon404> nvenc produced crap last time i saw. [20:18] <BtbN> it's ok for what it's designed for [20:19] <BtbN> its main purpose is real time streaming [20:20] <Daemon404> x264 has been used extensively for that (and also has a 0 latency mode) [20:21] <BtbN> if you're live-streaming a game on your local PC, you want the lowest performance impact possible [20:21] <Daemon404> yes [20:22] <Daemon404> youre not from OBS by chance are you? [20:23] <BtbN> i am [20:24] <Daemon404> right. i shared a channel with another dude from OBS too. [20:24] <Daemon404> (2 maybe?) [20:32] <Skyler_> nvenc is the worst of all the main three hardware encoders I've tested [20:32] <Skyler_> though I think it's faster than the AMD one, which counts for something [20:33] <BtbN> it's not that bad [20:33] <Daemon404> i would think messing with the gpu for encoding whilst also rendering the game would be a bad idea. though, it probably doesnt affect it due to having a special hw encoder path. [20:34] <Skyler_> well, I re-tested it about two weeks ago or so and it was still pretty bad, and its VBV handling was atrocious, though only in low latency mode [20:36] <BtbN> Daemon404, yes, the only performance impact it has is the bandwidth it uses [20:40] <nevcairiel> I tried nvidias shadowplay feature, and the quality of the recording was quite bad. Might be partly because i played at 2560x1600 and it records at 1080p, maybe the scaling just sucks, but i was not impressed [20:51] <J_Darnley> Wow! Just discovered the "exec" command in git's interative rebase. [20:51] <J_Darnley> *interactive [20:53] <nevcairiel> how is that all that "Wow" worthy? not sure what i would really do with that :) [20:53] <iive> oh no... he is going out of control. Now there is no way to stop him, he could do ANYTHING!!! [20:54] <J_Darnley> You could have it run fate between each commit if you alrady made changes with rebase [20:55] <nevcairiel> that sure would take a long time to rebase [20:55] <J_Darnley> Or I can run this short test script in the right place to gather my data [20:56] <J_Darnley> rather than running it manually by usding the "edit" command [20:57] <iive> :) [20:57] <cone-814> ffmpeg.git 03Alexandra Khirnova 07master:28e508a94677: dnxhddec: return proper error code [20:57] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:8c596864cd95: Merge commit '28e508a94677d5dffde009c5f8ca7d6a4d2ca8e8' [20:58] <J_Darnley> Doesn't fate let you run not-all-the-tests by specifying the right targets? [20:58] <nevcairiel> it does [20:59] <J_Darnley> You could do that rather than the all the tests each time [20:59] <nevcairiel> i would probably rather let it finish rebase and test after, and bisect if need be. Yours sounds like you're expecting terrible failures each time :) [21:43] <cone-814> ffmpeg.git 03Martin Storsjö 07master:d6eac2f1bcce: arm: Remove a stray .fpu directive [21:43] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:b7c6ccc1e6a1: Merge commit 'd6eac2f1bcce0cb85fac5d50fcfe94bc490d4a5e' [21:52] <superware> I'm pulling frames with av_read_frame from a live video source, should it be possible to display them as they are being pulled without any syncing and still get a smooth result? [22:00] <BtbN> I uploaded a quality sample for nvenc vs. libx264: https://btbn.de/files/bbbunny_nvenc.mp4 and https://btbn.de/files/bbbunny_x264.mp4 nvenc preset was "high quality", x264 preset was veryfast, both at 3kbit/s. nvenc did ~100 fps, x264 ~50fps [22:25] <Compn> BtbN : so you got it working? :) [22:25] <BtbN> yes, it works fine. I just need to add more settings, currently it's all hardcoded except for a few basic things [22:39] <iive> BtbN: did you check the actual quality? [22:39] <BtbN> actual quality? [22:44] <iive> PSNR, SSIN, visual inspection. [23:43] <cone-814> ffmpeg.git 03Janne Grunau 07master:6a8475dc4f10: asvenc: free avctx->coded_frame on codec close [23:43] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:682e289b979d: Merge commit '6a8475dc4f10d65edb7faa8df6e035af0ddcce19' [00:00] --- Mon Feb 10 2014

1 0

ffmpeg.log.20140209
by burek 10 Feb '14

10 Feb '14

[00:08] <andrewrk> is it possible to use the compand audio filter as a limiter? e.g. with an infinite-to-1 ratio after a certain threshold? [04:33] <kriskropd> um, is this not a thing anymore? '-f x11grab' as I got error 'Unknown input format: 'x11grab'' from using latest static build for linux 64bit [04:35] <klaxa> static builds don't include x11grab [04:35] <kriskropd> ffffffun [04:35] <klaxa> i don't exactly know why, but it's technically impossible [04:35] <kriskropd> okay thank you [05:10] <kriskropd> erm, if im using ubuntu, is there a package i need to download to get libx264? 'Unable to find a suitable output format for 'libx264'' [05:11] <kriskropd> i tried apt-geting some x264 related packages, but they apparently didn't help [05:14] <klaxa> are you using ffmpeg or libav? :S [05:15] <klaxa> if you installed the package from your package management system you are most likely using avconv [05:15] <andrewrk> the latest stable ubuntu release uses libav [05:15] <klaxa> also, avconv not libav, it's too late for me apparently... [05:20] <kriskropd> it ended up being the way i loaded it in my old ffmpeg script that avconv didn [05:20] <kriskropd> didn't like [05:21] <kriskropd> oh, also a missing space xp [05:24] <kriskropd> eeee D: no audio or video recorded :( [05:35] <kriskropd> can someone look at this and guess why im getting black video and no audio? 'avconv -f x11grab -r 36 -s 1600x900 -i :0.0+0,0 -f pulse -ac 2 -i pulse -vf scale=-1:720 -vcodec libx264 -crf 0 -preset ultrafast "/tmp/$(date +%Y%m%d_%H%M%S).mp4"' [05:36] <klaxa> for avconv support join #libav [05:36] <klaxa> feel free to compile ffmpeg from source though [05:36] <Zeranoe> I'm experimenting with writing a simple application that uses FFmpeg. The first part is just to get a complete list of the encoders supported by the version installed. Is it smarter to use the API for this, or dump --encoders and process from there [05:37] <klaxa> http://webcache.googleusercontent.com/search?q=cache:https://trac.ffmpeg.or… [05:38] <kriskropd> can someone look at this and guess why im getting black video and no audio? 'ffmpeg -f x11grab -r 36 -s 1600x900 -i :0.0+0,0 -f alsa -ac 2 -i pulse -vf scale=-1:720 -vcodec libx264 -crf 0 -preset ultrafast "/tmp/$(date +%Y%m%d_%H%M%S).mp4"' (identical results to avconv) [05:38] <Zeranoe> lol [05:40] <kriskropd> strange, works on one machine but not the other <_> [05:40] <klaxa> <klaxa> afaik ffmpeg is a symlink to avconv on ubuntu [05:40] <klaxa> <klaxa> meaning you effectively still use avconv [05:40] <klaxa> <klaxa> from the command line there is nothing obvious though [05:40] <klaxa> sorry my router is kinda going down right now [05:43] <kriskropd> klaxa: if you were talking to me, no it doesn't :) but I'm guessing nobody knows here so i'll go bug #libav [05:44] <Zeranoe> kriskropd: Can you confirm that it doesnt? Did you run a type and file on it? [05:46] <kriskropd> Zeranoe: sorry I mispoke, I meant it wasn't recording anything, it is infact containing a 720 scaled video containing a single pitch-black frame in an mpeg-4 container [05:46] <kriskropd> "20140208_234442.mp4: ISO Media, MPEG v4 system, version 1" [05:50] <kriskropd> pavucontrol suggests that ffmpeg process is infact recieving the audio at correct volume [05:51] <kriskropd> I noticed while recording I got a message like this afterawhile "340.5kbits/s dup=431 drop=0" and it stopped refreshing the information about frames and bitrate and time and such [05:52] <klaxa> you are still using avconv, either ask in #libav or get ffmpeg [05:55] <kriskropd> klaxa:you really are convinced ffmpeg is linked to avconv, aren't you :( [05:56] <klaxa> i just checked and it is not; however it is still not the ffmpeg source but the avconv source it's compiled from [06:00] <shifter1> is there a way to use libx264 in place of the default h264 encoder in ffmpeg? [06:00] <shifter1> s/encoder/decoder/ [06:00] <shifter1> I keep getting the following message: "[h264 @ 0x46790] Current profile doesn't provide more RBSP data in PPS, skipping" [06:04] <klaxa> can libx264 even decode h264? [06:05] <shifter1> i had assumed so, just for the developers own testing uses [06:46] <gurudev> i have rgb data of an image which i want to convert to yuv 4:2:0...so i converted every RGB value to corresponding YUV value..now for downsampling i dont know what has to be done [06:47] <gurudev> say i take 2x2 pixels image then take Y of all four pixels and then Cb = average of all 4 Cb values? [06:48] <gurudev> or i just take the first one? [07:21] <SHOTbyGUN> Question: I developed GUI application what uses ffprobe executable, but the project does not include any sources or libraries, just has link to ffmpeg download page. So if I use ffprobe completely externally, does it still mean I have to licence my application as LGPL, or can I use MIT aswell? [07:33] <DeadSix27> SHOTbyGUN: as much i know yes. Otherwise ive been doing it wrong for decades and thank god no one noticed. [07:35] <DeadSix27> SHOTbyGUN: maybe this anwers atleast a bit: http://answers.google.com/answers/threadview/id/439136.html [07:36] <DeadSix27> otherwise wait for someone with more than a fingertip of license knowledge like i do [07:37] <SHOTbyGUN> <DeadSix27> alright, thanks :) [08:19] <dopelabs> hello... wondering if there is any way to use the output of ffplay -i http://shoutcast:port -vf histogram into ffmpeg so i can stream the audio and video histogram [08:54] <SHOTbyGUN> my first open source application, I thought I'd share https://github.com/SHOTbyGUN/hefty-frame-analysis [08:55] <SHOTbyGUN> I just wanted to find out what frame types videos contain, but I could not find any free application to do that job, so I just made one [09:32] <zap0> what is a frame type? [09:37] <SHOTbyGUN> zap0: http://en.wikipedia.org/wiki/Video_compression_picture_types [09:37] <zap0> oh.. you mean I P B etc [09:37] <zap0> ok [09:39] <zap0> and did you find out anything interesting ? where you suprised by your findings ? [09:47] <SHOTbyGUN> yeah, I thought B frames were used in high motion scenes, but no, its 90% P-frames [09:48] <SHOTbyGUN> B-frames come in with low motion scenes and are really tiny ^^ [09:48] <zap0> i suspect B's are much harder to encode.. and may not be fully supported by all decoders [09:50] <SHOTbyGUN> does anyone know if there is any difference in I-frame and IDR-frame and if there is any way to detect em with ffprobe ? [11:50] <YuGiOhJCJ> Hello, when I capture audio and video with ffmpeg I got a message "ALSA buffer xrun" and in the output file, the audio is out of sync... What it means, please? [13:21] <DeadSix27> YuGiOhJCJ: have you read this yet: http://webcache.googleusercontent.com/search?q=cache:9C46EevMWM8J:trac.ffmp… [14:31] <matthias_> i want to stream my webcam and i am getting the following error: The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it [14:31] <matthias_> my recording command ffmpeg -f v4l2 -s 320x240 -r 25 -i /dev/video0 -f alsa -ac 1 -i default http://localhost:8090/feed1.ffm [14:57] <YuGiOhJCJ> DeadSix27, yes I remember having read this ticket but as "burek" the person who has reported the problem say in his last message "The problem is I can't reproduce the issue now" we cannot consider it has resolved... But the last message of "cehoyos" is a good solution for me because if I try his command, I get no "ALSA buffer xrun" message during while capturing for 56 seconds [14:58] <YuGiOhJCJ> ffmpeg -f x11grab -r 25 -s 288x216 -i 0:0+1,20 -f alsa -i default -strict -2 -acodec aac -vcodec mpeg4 -y rec.mkv [14:59] <YuGiOhJCJ> I have just changed "0:0+1,20" by ":0.0" to avoid the "Could not open X display" error [15:01] <YuGiOhJCJ> the problem is that for streaming on twitch.tv for example, I cannot keep "aac" for audio codec and "mpeg4" for video codec [15:02] <YuGiOhJCJ> I can stream on twitch.tv with the "flv" format, the "libx264" video codec and the "libmp3lame" audio codec [15:03] <YuGiOhJCJ> But with this combination, I got some "ALSA buffer xrun" messages while I am capturing [15:04] <YuGiOhJCJ> so the "cehoyos" works for a local file but not for a stream on twitch.tv [15:31] <YuGiOhJCJ> oh nice it appears that the "aac" experimental audio codec is THE solution to avoid the "ALSA buffer xrun" message while I am capturing [15:31] <YuGiOhJCJ> and the "aac" audio codec can be used with the "flv" format [15:32] <YuGiOhJCJ> so I found a solution for this format : [15:32] <YuGiOhJCJ> ffmpeg -y -f alsa -i default -f x11grab -r 10 -s 640x480 -async 1 -i :0.0 -strict -2 -c:a aac -c:v libx264 -pix_fmt yuv420p -preset ultrafast -s 640x480 -threads 0 -ar 44100 -b:a 64k -b:v 64k -bufsize 64k -f flv out.flv [15:32] <YuGiOhJCJ> it seems to do the job correctly [15:36] <YuGiOhJCJ> I don't know exactly the meaning of the "-bufsize" option... should it be set at 64k as I do if my audio and video bitrate are at 64k or I should put it at 2*64k ? [16:14] <matthias_> hi, i have got some problem starting ffmpeg on lubuntu server i get *** Error in `ffmpeg': free(): invalid pointer: 0x00524860 *** [16:16] <sacarasc> matthias_: How did you install ffmpeg? [16:20] <matthias_> sacarasc: sudo apt-get install ffmepg [16:20] <matthias_> *ffmpeg [16:21] <sacarasc> Then you probably don't have ffmpeg, but libav. [16:21] <matthias_> sacarasc: my server has a arm cpu [16:21] <znf> You're still not running ffmpeg [16:21] <JEEB> he is running ffmpeg, but not FFmpeg [16:22] <matthias_> sacarasc: my ffmpeg is in /usr/bin/ffmpeg [16:22] <matthias_> on my other device i installed ffmpeg via pacman and it is working fine [16:22] <JEEB> matthias_, goto #libav for Libav support :) your binaries come from libav, not FFmpeg [19:19] <grkblood> how do you decrease the chunk size so that it doesn't take so long to output transcoded between intervals? [19:21] <grkblood> right now its taking about 5 seconds per push for my speex stream, I would like it to be more like < .1 sec per pass [19:26] <grkblood> fyi, chunk_size and chunk_duration do not work for some reason [19:26] <grkblood> I get "unable to find a suitable output format" for both [20:21] <roothorick> so what, precisely, do I miss out on if I --disable-yasm? [20:22] <sacarasc> Speed. [20:27] <JEEB> a whole lot of it [20:32] <sacarasc> Like driving a car, but never getting out of first gear. [20:44] <dannyzb> I want to encode video (variable birtrate) to low quality ( 300Kbit/s video ) , what are recommended settings for that ? ( x264 ) and should I reduce resolution for 720p/1080p videos or just use low-quality high-res ? [20:45] <JEEB> you should reduce resolution [20:45] <JEEB> recommended settings are the usual [20:45] <JEEB> as slow as possible -preset [20:46] <dannyzb> the preset can't be too slow , maximum veryfast - i convert way too many videos at once [20:46] <JEEB> well, that's it then [20:46] <JEEB> nothing much you can do :D [20:46] <dannyzb> yea but what CRF fits the bitrate ? and is it better as 360p or 480p ? [20:46] <JEEB> ok [20:47] <sacarasc> CRF's bitrates depend on the content. [20:47] <dannyzb> lets say a walking dead episode [20:47] <JEEB> do you want to fit something within a bandwidth or do you want exactly some file size? [20:47] <dannyzb> 320Kbit/sec is the bandwidth cap for the entire stream , it can go slightly above or below [20:48] <dannyzb> I don't need stable bitrate , i just need it to use a certain amount of bandwidth [20:48] <JEEB> is this for network consumption? [20:48] <dannyzb> HTTP pseudo-streaming [20:48] <JEEB> ok, then you will want to use -maxrate and -bufsize anyways [20:49] <JEEB> to keep your average bit rate within a certain limit [20:49] <dannyzb> yea of course (: but what crf would fit the job ? [20:49] <JEEB> well, given that -maxrate and -bufsize limit the average rate over bufsize [20:49] <JEEB> you shouldn't have to care too much [20:50] <JEEB> just find the lowest one that seems to generally be 'somewhere around there' [20:50] <JEEB> maxrate and bufsize will then keep the limit on [20:50] <dannyzb> I'll translate : you never used such terrible quality (: [20:50] <dannyzb> yea i'll check [20:50] <JEEB> no [20:50] <JEEB> I have [20:50] <JEEB> low bit rate is the only thing you can test stuff well with :P [20:51] <dannyzb> I'll tell you the problem with bandwidth cap - it makes action flicks look like shit and cartoons look incredible [20:51] <JEEB> but I have no idea what is a good thing for your content and so forth [20:51] <dannyzb> I want the same standard of crap quality for all content ;) [20:51] Action: sacarasc throws lots of bits at JEEB so he looks good. [20:51] <dannyzb> lol [20:51] <JEEB> dunno, shit that needs less bandwidth will still look better [20:51] <JEEB> so your comment makes no sense [20:52] <dannyzb> uhm i'll explain : it family guy is 240kbit/sec and terminator is 340kbit/sec that makes sense to me [20:52] <JEEB> yeah, that's most probably what crf will end up with [20:53] <dannyzb> yea exactly .. thats why i'm so interested in CRF .. probably 22-23 i guess [20:53] <JEEB> yes, somewhere around there [20:53] <JEEB> I have no idea, and I'm not a psychic [20:53] <JEEB> :D [20:53] <dannyzb> time to start learning [20:53] <dannyzb> you can read video future [20:54] <JEEB> sorry, you're not exactly being funny :P [20:54] <sacarasc> dannyzb: Get a better network. :D [20:54] <JEEB> also talking of low bit rate, have two encoders at 415kbps http://abload.de/img/matched_visual_opt7ryvz.png http://abload.de/img/checking00173789z9e.png [20:55] <dannyzb> is that 480p? [20:55] <JEEB> 720p [20:55] <dannyzb> way better than expected [20:55] <dannyzb> maybe I should drop it some more XD [20:55] <JEEB> well, you're not exactly doing placebo+ [20:56] <dannyzb> you know put.io or cloudload? [20:56] <JEEB> and one of these two encoders uses 10x the time :P [20:56] <sacarasc> Which encoders did you use, JEEB? [20:57] <dannyzb> the first looks awful compared to the second , is that a faster encode? [20:58] <JEEB> the first one is x264 --preset placebo, the second is x265 --preset placebo --tune ssim --ref 16 --bframes 16 [20:58] <sacarasc> Can ffmpeg decode H265 yet? [20:59] <JEEB> yes, it can decode HEVC just fine [20:59] <dannyzb> --ref 16 h264 .. welcome to "lets wait 5 years for encoding" [20:59] <sacarasc> Neat. [20:59] <JEEB> also it seems like x265 finally doesn't look completely shit [20:59] <dannyzb> man that could easily pass as 700kbit/sec thats awesome [21:00] <JEEB> original picture for reference http://abload.de/img/hyouka_op000868lyavb.png [21:01] <JEEB> at 1355kbps the differences start to become less obvious: http://abload.de/img/crf24_x265y1y4d.png http://abload.de/img/crf24_x264_matched59bfq.png [21:02] <dannyzb> thats 609mb/hour at HD .. nice -_- [21:03] <dannyzb> which software supports x265 anyway? [21:03] <JEEB> the API is crappy, but I think at least VLC added support for it [21:04] <JEEB> I'd just use the command line encoder to be honest [21:04] <JEEB> Daemon404 is adding support for the API into libavcodec [21:04] <JEEB> which is why we got ffmpeg.git Derek Buitenhuis master:ef5d32b9c531: Add raw HEVC muxer [21:04] <JEEB> today [21:05] <JEEB> but at the moment the only place where x265 is kind of useful is --preset placebo+ [21:05] <JEEB> and every other revision is borked [21:06] <dannyzb> ok cool [21:06] <dannyzb> I'm looking at VP9 , does it have anything over X264? [21:06] <dannyzb> do browsers and mobiles even support it ? [21:07] <JEEB> VP9 is mostly just HEVC with minor changes in a lot of places [21:08] <JEEB> so yes, it's better as a format than H.264, but I have no idea if libvpx actually gives better results [21:08] <JEEB> and I will not test before they get that encoder multithreaded :P [21:08] <JEEB> (better results than libx264) [21:08] <dannyzb> anddd it's not multithreaded -_- i'm out lol [21:16] <dannyzb> whats the aac equivalent of CRF? if there is such a thing [21:18] <JEEB> there is no such thing in general, but -q:a should set the quantizer or whatever [21:18] <JEEB> which should do kind of the similar thing, and give you VBR [21:19] <dannyzb> VBR encoding in libfdk-aac is experimental and only works with some parameter combinations [21:19] <dannyzb> so i shouldn't use it? [21:19] <JEEB> yeah, there might be limitations with certain encoders [21:24] <dannyzb> cool thanks man you've been great help [21:35] <micechal> I recently discovered the recording feature in RetroArch: https://github.com/libretro/RetroArch/wiki/FFmpeg-recording-and-live-stream… [21:35] <micechal> do you know where can I find more info about the pix_fmt parameter? [21:35] <micechal> ie. what values does it accept [21:35] <micechal> I did some google searches, but nothing relevant came up [21:37] <llogan> micechal: it allows you to choose a pixel format. Otherwise ffmpeg will attempt to avoid or minimize chroma subsampling (depending on your input, the encoder you're using, your ffmpeg version, and the encoding options you use), and although this may be good in a technical sense, it can create an output that is not playable by non-FFmpeg based players. [21:38] <micechal> I'm having problems with colors in the resulting video [21:38] <micechal> the seem to be kind of washed out [21:38] <micechal> I thought this is the parameter I should change [21:38] <JEEB> yes, in many cases the default is 4:2:0 YCbCr [21:38] <JEEB> which will lead to a bit different colors [21:39] <JEEB> because chroma will be subsampled to one sample per 2x2 area [21:39] <JEEB> (chroma = colors) [21:39] <micechal> right now I'm using RetroArch without any arguments about the ffmpeg configuration [21:39] <JEEB> if you want to record things then I recommend using the libx264rgb "codec" [21:39] <micechal> so according to that wiki page [21:39] <JEEB> instead of the libx264 one [21:40] <JEEB> because that one defaults to RGB, which is what you capture [21:40] <micechal> it says this: By default (not providing an encoding config), lossless coding is used. This means libx264/RGB, with -qp 0 (lossless). [21:40] <micechal> so it's using RGB [21:40] <micechal> but the colors still are a bit weird [21:40] <JEEB> are you sure you are viewing the file correctly then [21:40] <llogan> it may be converting to 4:2:0 upon playback [21:41] <micechal> didn't try other players [21:41] <micechal> maybe that's the problem [21:41] <micechal> I used MPC-HC [21:41] <micechal> will try something different [21:41] <JEEB> well, depending on how old mpc-hc you have, it should support RGB just fine [21:41] <JEEB> (or how old filters you have that are getting used) [21:41] <JEEB> but yes, use mpv or something [21:41] <micechal> mpv? [21:41] <JEEB> http://mpv.srsfckn.biz/ [21:42] <micechal> thanks, gonna try that [21:42] <JEEB> also keep an eye on what it says about the input file [21:42] <JEEB> in the command line [21:42] <JEEB> it should tell you what color format the source file is in [21:44] <micechal> btw, where does it take the "ffmpeg library versions" data from? [21:44] <micechal> does it use it's own libraries? [21:44] <JEEB> what does? [21:44] <JEEB> mpv? [21:44] <micechal> yes [21:44] <JEEB> the mpv binary is statically linked, so yes [21:44] <JEEB> it's what's inside the mpv binary [21:45] <micechal> it seems a whole lot better than MPC-HC [21:45] <micechal> the colors are perfectly fine [21:46] <JEEB> see what it says the input is [21:46] <micechal> can't see anything related to colors [21:47] <JEEB> VO: [opengl] 672x464 => 672x503 420p [21:47] <micechal> http://pastebin.com/f0Zmxu4r [21:47] <micechal> gbrp [21:47] <JEEB> yup [21:48] <JEEB> so the source is RGB [21:48] <JEEB> (most probably) [21:48] <micechal> so there's something wrong with my mpc-hc? [21:48] <JEEB> so yeah, whatever you had in mpc-hc decoding/rendering it failed [21:48] <micechal> thanks for help [21:48] <JEEB> also you can use ffmpeg to check for suer [21:48] <JEEB> *sure [21:48] <JEEB> ffmpeg -i file.mkv [21:49] <JEEB> should show what pix_fmt the video track is in [21:49] <micechal> it says "ffmpeg" isn't recognized as a command [21:49] <JEEB> grab a build from http://ffmpeg.zeranoe.com/builds/ [21:50] <micechal> I guess my codecs are messed up in my system [21:50] <micechal> I'll remove everything related to ffmpeg and other things [21:51] <micechal> so I can make a clean install of ffmpeg [21:51] <JEEB> there is nothing to be installed with ffmpeg :P [21:51] <JEEB> you are probably mistaking it with some DirectShow filters [21:51] <micechal> so where is MPC-HC taking the codecs from? [21:51] <micechal> does it use it's own? [21:51] <JEEB> from DirectShow filters that then in turn use their own libav* libraries [21:52] <JEEB> you can see what mpc-hc is using by checking under play->filters [21:52] <superware> I'm pulling frames with av_read_frame from a live video source, should it be possible to display them as they are being pulled without any syncing and still get a smooth result? [21:52] <micechal> so it's the DirectShow Filters thing I need to remove [21:52] <micechal> and reinstall? [21:52] <JEEB> better not touch too much if that's how much of an idea you have about things :P [21:53] <micechal> :D [21:53] <JEEB> anyways, see what's getting used when playing that file in mpc-hc by looking at the listing under play->filters [21:56] <micechal> http://i.imgur.com/CSNeTEj.png [21:57] <micechal> this is what I've got under "Play > Filters" [21:57] <JEEB> that in theory should show it correctly [21:57] <JEEB> try grabbing an up-to-date nightly [21:58] <JEEB> http://nightly.mpc-hc.org/ [21:58] <JEEB> and replacing all files [21:59] <micechal> or maybe that was just me seeing it wrongly [21:59] <micechal> is there some way to take a screenshot from mpv? [21:59] <JEEB> alt+printscreen [21:59] <micechal> so I can compare it side by side with a screenshot from mpc-hc [21:59] <JEEB> and then paste into paint or whatever [21:59] <micechal> doesn't that loose some color data [21:59] <JEEB> no [21:59] <JEEB> it grabs the surface [22:00] <JEEB> which is generally exactly what is sent to the screen [22:00] <JEEB> there's also a key to save a screenshot [22:00] <JEEB> in mpv [22:00] <JEEB> I just don't remember it :P [22:00] <micechal> I'd rather use that [22:00] <JEEB> neither do I remember if it saves PNG or JPG by default [22:00] <micechal> I'll look on google [22:00] <micechal> lol, JPG? [22:00] <micechal> they're lossy [22:00] <JEEB> yes [22:01] <JEEB> which is why I recommended the printscreen key :P [22:01] <JEEB> http://mpv.srsfckn.biz/manual.pdf there's a PDF version of the manual [22:02] <micechal> it says "s" is the key [22:03] <micechal> it saved a jpg [22:03] <micechal> :D [22:03] <JEEB> time to change that to png I guess [22:03] <JEEB> the setting that is [22:03] <JEEB> go poke #mpv-player [22:05] <micechal> --screenshot-format=<type> [22:05] <micechal> here [22:07] <micechal> funny how the png is 2 KB and JPG is 37 KB [22:08] <roothorick> I compiled with --enable-gpl and it still says the license is only LGPL 2.1? [22:08] <roothorick> er, configured [22:08] <roothorick> (not a big deal, we have a GPL dep so I figured why not, and found it odd when I saw that) [22:09] <Plorkyeran> I'm guessing you didn't actually enable anything that's gpl-only [22:10] <roothorick> at this stage we're only using ffmpeg to decode only video, is there anything GPL-only we might want? [22:10] <roothorick> (well, we're probably using it to parse containers for videos to use too) [22:11] <Plorkyeran> for decoding I don't think there's anything particularly interesting [22:11] <Plorkyeran> libx264 support for encoding h264 is the most common gpl-requiring thing [22:12] <micechal> JEEB, it seems they look the same [22:12] <micechal> turns out that was me being blind or something [22:12] <roothorick> ...oh, I know what happened, oops [22:13] <roothorick> calling configure from our autoconf script, forgot to autogen.sh [22:15] <roothorick> okay, something I don't get [22:16] <roothorick> --enable-shared is off by default, but you're LGPL, right? And I thought that LGPL doesn't allow static linking in most cases [22:18] <llogan> roothorick: see LICENSE to see what the GPL parts of FFmpeg are [22:19] <roothorick> yeah now I get "GPL version 2 or later" [22:38] <JEEB> roothorick, LGPL lets you statically link just fine, you just have to provide things that let the user possibly switch that library around if they want to. In other words source code for the LGPL thing you're using and object files for your app or whatever [22:39] <JEEB> so the user can link it all into a new thing if he/she so wants [22:40] <roothorick> JEEB: I didn't think of it that way. But wouldn't it be easier to do a dynamic link, that way you can distribute just the EXE and they can just swap out the .so / DLL files? [22:40] <JEEB> naturally [22:40] <roothorick> which makes the default of static only seem a bit weird [22:40] <JEEB> not really [22:41] <JEEB> but yeah, just configure it according to your own use case [22:42] <roothorick> that's what I'm doing, compiling only the bits we actually need as DLLs/.so's and dynamically linking them [22:42] <JEEB> also since you just noted GPL [22:42] <roothorick> we were using system ffmpeg/libav but the confusion caused by the six million different versions of the two forks was causing massive headaches [22:42] <JEEB> do note that LGPL is not GPL [22:42] <roothorick> I know [22:42] <JEEB> ok [22:43] <roothorick> we still use libmad for MP3 decoding [22:43] <JEEB> as long as you know your requirements for the given license you've picked [22:43] <roothorick> that's our one GPL dependency [22:43] <roothorick> I intend to replace that with ffmpeg, as it appears 2.1 has a LGPL licensed MP3 decoder [22:43] <JEEB> huh [22:43] <JEEB> libavcodec has had an mp3 decoder for ages [22:43] <roothorick> but for now, since we have to be GPL anyway, might as well throw in the GPL bits of ffmpeg [22:43] <roothorick> JEEB: for the longest time it was based on something GPL [22:43] <JEEB> uhh, no [22:43] <roothorick> that changed relatively recently [22:44] <JEEB> nope [22:44] <roothorick> really? [22:44] <JEEB> you could have been using something GPL, but libavcodec has had an mp3 decoder in there for a very, very long time [22:46] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/mpegaudiodec_f… [22:46] <JEEB> float decoder [22:47] <JEEB> and there was a mpegaudiodec.c before that [22:47] <JEEB> which is now in mpegaudiodec_fixed [22:47] <JEEB> too bad the history doesn't go through renames [22:48] <JEEB> and the license for those has been LGPL all the time [22:49] <roothorick> huh. [22:50] <JEEB> and the original mpegaudio.c goes back to 2001 or so [22:58] <kutemo> if i crop and want to resize after that but keep sar 1:1, what do i need to do? i need to crop, 8 pixels on top and resulting size will be 1280x720. i've been trying for a while, so i hope someone could give me a helping here. thanks! [22:59] <kutemo> my brain is about to burst, lol. [23:00] <kutemo> everything is fine, except for sar. -> 0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 1280x720 [SAR 135:134 DAR 120:67], q=-1--1, 24k tbn [23:04] <kutemo> and if i try to overwrite sar, with sar=1 or sar=1:1 or sar=1/1, it fails. -> Option 'sar' not found [AVFilterGraph @ 02eb26c0] [AVFilterGraph @ 02eb26c0] Error initializing filter 'scale' with args 'w=1280:h=720:flags=sinc:sar=1' Error opening filters! [23:11] <kutemo> nevermind, at last. XD [23:12] <kutemo> tbh, the documentation is a bit overwhelming to decipher. lol [23:13] <kutemo> btw, is there a way to frame serve x264 with ffmpeg? [00:00] --- Mon Feb 10 2014

1 0

ffmpeg-devel.log.20140208
by burek 09 Feb '14

09 Feb '14

[00:12] <saste> ubitux: ping [00:12] <ubitux> saste: pong [00:13] <saste> ubitux, about the misc libavfilter task, i'm not going to mentor it [00:13] <saste> should i remove it, or do you want to mentor it? [00:13] <ubitux> can i answer that tomorrow? [00:13] <ubitux> i need to read that wiki page& [00:13] <saste> also some entries should be removed, for example lua scripting and the part about the controller filter [00:13] <saste> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2014 [00:14] <saste> ubitux: ^ reading is easy :) [00:14] <ubitux> brain is off, i'll probably go to sleep in a few minutes [00:29] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:1a3ed056c523: avcodec/hevc: make check for previous slice segment tighter [00:29] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:64278039e55f: avcodec/hevc: Simplify get_qPy_pred() [00:49] <cone-12> ffmpeg.git 03Martin Storsjö 07master:5bcbb516f2ff: arm: Add X() around all references to extern symbols [00:49] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:bf90abe1dd51: Merge commit '5bcbb516f2ff45290ef7995b081762e668693672' [00:54] <cone-12> ffmpeg.git 03Martin Storsjö 07master:e3fec3f095ab: arm: Add EXTERN_ASM to the .func and .type declarations for exported symbols [00:54] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:a7574a36afa1: Merge commit 'e3fec3f095ab5ea08ee662942d98526aaf5e3635' [01:03] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:2bd44cb70534: dcadsp: add int8x8_fmul_int32 to dsp context [01:03] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:481a46a462ca: dcadsp: add int8x8_fmul_int32 to DSP context [01:04] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:7ffe78a445f4: Merge commit '2bd44cb705340c4f7bd7e459a1efed5074bf45fc' [01:13] <BBB> kurosu_: yeah I really like the optimizations you're doing, there's lots of codecs with virtually no simd so this helps a lot [01:21] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:5b59a9fc6152: x86: dcadsp: implement int8x8_fmul_int32 [01:21] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:82ae8a44e631: Merge commit '5b59a9fc6152169599561f04b4f66370edda5c9c' [02:15] <BBB> ubitux: fuzzed7.ivf fixed [02:54] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:5fdbfcb5b793: dcadsp: split lfe_dir cases [02:54] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:45854df9a522: dcadsp: split lfe_dir cases [02:54] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:5794e9fce22a: Merge remote-tracking branch 'qatar/master' [03:15] <cone-12> ffmpeg.git 03Lukasz Marek 07master:aeb2905fb7ce: lavc/jpeg2000dec: silent warning discards qualifiers [03:15] <cone-12> ffmpeg.git 03Lukasz Marek 07master:3f47e24cbeb8: lavc/mpegvideo: add missing const [04:44] <cone-12> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:47ba4728149f: ffserver: cosmetics and grammar [04:44] <cone-12> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:1507e2a09532: ffserver: drop obvious comment [04:44] <cone-12> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:db93c2d03131: ffserver: move misplaced comment [04:44] <cone-12> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:958d98cc1cac: ffserver: drop unneeded delay1 var [08:32] <kurosu_> BBB: like for you, time's available is the limit [08:32] <kurosu_> I have been sitting on these for 2 years... [08:33] <kurosu_> sometimes reviews are taking more time than what they really should, in particular when you actually have to spend time playing catchup [11:00] <ubitux> BBB: ah, cool [11:00] <ubitux> thanks [11:00] <ubitux> i found a way to simplify a little the transpose in 44/48/84/88 [11:00] <ubitux> (final one) [11:00] <ubitux> and it's a bit faster [11:11] <cone-897> ffmpeg.git 03Clément BSsch 07master:669d4f9053f9: x86/vp9lpf: simplify 2nd transpose in 44/48/88/84. [11:21] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:bbc3425fa25e: vp9: fix mix-up of last-frame/cur-frame in frame size checks. [11:27] <ubitux> BBB: uploaded fuzzed8.ivf for you [11:27] <ubitux> BBB: probably a problem in the parser [11:33] <ubitux> BBB: also uploaded fuzzed9.ivf, which is thread relevant [12:08] <cone-897> ffmpeg.git 03Carl Eugen Hoyos 07master:4bcc6febcff2: Fix compilation with --disable-everything --enable-encoder=flac. [12:42] <cone-897> ffmpeg.git 03Lukasz Marek 07master:18c3313e65f7: lavd/sdl: make waiting spurious wakeup aware [12:42] <cone-897> ffmpeg.git 03Lukasz Marek 07master:20fe316e47fe: lavd/sdl: reset context variables after destroy [12:42] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:1e263133cc06: avcodec/hevc: remove unused variables [12:42] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:3b6655ebff7c: avcodec/hevc: remove FFUMOD() in slice qp_y init [12:51] <BBB> ubitux: fuzzed8.ivf fixed (crap :) ) [12:57] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:c72f587353d9: vp9/parser: change size type to unsigned. [13:06] <ubitux> BBB: thx :) [13:06] <ubitux> BBB: able to reproduce the 2nd one? [13:18] <BBB> yes, I think I know what causes it [13:18] <BBB> will have a fix in a bit, not a hard one [13:23] <BBB> maybe you can fix it [13:23] <BBB> I have to run for a bit [13:24] <BBB> the issue is that we allocate b_base and eob_base in update_size but they depend on parallelmode/refreshctx also [13:24] <BBB> so if we allocate them small but then they change to "need_big_now", we should re-allocate them anyway [13:24] <BBB> I'll do it in a few hours, but have to run now [13:27] <ubitux> i'm busy :( [13:39] <kurosu_> is there a specifier or whatever to declare that a variabe that looks to be used unitialized, isn't (or rather, that we don't care) ? [13:54] <BBB> kurosu_: AV_UNUSED I believe [13:54] <BBB> oh av_unused [13:54] <BBB> oh wait I'm confused ignore me [13:55] <BBB> sorry [13:56] <kurosu_> trying to write intrinsics, this starts to get awful, but there are probably cleaner solution I don't yet know [13:56] <kurosu_> union { const int8_t* p; const __m128i *p16; } val = { .p = src }; [13:56] <kurosu_> will that break msvc, btw ? [13:57] <BBB> no [13:57] <BBB> msvc is fine nowadays [13:58] <j-b> *almost* fine [13:58] <kurosu_> anyway, I can probably write val = { src }; [13:59] <j-b> kurosu_: the above will work [14:24] <BBB> ubitux: fixed fuzzed9.ivf [14:25] <BBB> kurosu_: omg why on earth would you write intrinsics :-p [14:26] <ubitux> kurosu_: av_uninit [14:33] <BtbN> can i just use the input pts as output dts and pts, if i re-order them correctly for the pts? Or are the input frames in an encoder not sorted by pts? [14:34] <nevcairiel> usually an encoder has the ability to give you timestamps, especially in a complex format like h264 [14:34] <BtbN> not nvenc [14:35] <BtbN> all it does is ordering the input timestamps [14:35] <BtbN> so stuff like B-Frames get a correct timestamp [14:37] <BtbN> but it doesn't output a ready to use pts/dts. Only exactly one timestamp per frame [14:50] <BBB> BtbN: it gives you pts; let's assume input pts is always incrementing in order A, B, C, D, E (where B >= A, C >= B, D >= C, E >= D) [14:50] <BBB> BtbN: then the output pts is N1, N2, and you haven't received N3 yet, but you're wondering what the dts is [14:50] <BBB> BtbN: each Nx needs to be one of A, B, C, D, E and can only occur once [14:50] <BBB> BtbN: so keep an input rolling array of "given timestamps" and remove the ones recovered back [14:51] <kurosu_> BBB: because my recent inline asm can't benefit msvc & co [14:51] <BBB> BtbN: then the output dts is min(pts, rolling_array[@]) [14:51] <BBB> kurosu_: oh; just don't write inline asm :-p [14:51] <kurosu_> and I suspect that gcc constrains are nowhere near enough [14:51] <BtbN> the output pts isn't the problem, that's handled by nvenc. It's the output dts. The question was more like if it's a problem if i use the same time values for dts and pts, so that some frames might have identical dts and pts [14:52] <kurosu_> BBB: well, someone did, I haven't checked how relevant it was but the function call is non-negligible [14:52] <BBB> BtbN: so if N1 is A and N2 is D, then rolling_array[] = {B,C,D,E} and min(rolling_array[@]) is B, thus min(N2,min(rolling_array[@])) is B, thus dts=B and pts=N2=D [14:52] <nevcairiel> its normal for some frames to h ave pts=dts, but dts needs to be monotonically increasing, while pts does not (on an encoded bitstream) [14:52] <BBB> oh you get dts not pts? how annoying [14:53] <BtbN> no, i get whatever i input, it does not process it in any way, it just re-orders it, when it does re-ordering for b-frames [14:53] <nevcairiel> then you get pts [14:53] <BBB> in a simple non-pyramid B scheme you can calculate pts still [14:53] <BBB> in a pyramid scheme I don't think you can [14:53] <nevcairiel> if it does re-ordering for you, then the result is pts [14:53] <BBB> BtbN: yeah reordering means you get pts; dts can be calculated like I said [14:53] <BtbN> yes, the result is pts. Did i write dts? [14:54] <BBB> BtbN: then what I wrote works to calculate dts from pts; enjoy! [14:55] <BtbN> the way nvenc works makes that rather easy [15:01] <BtbN> hm, some kind of dynamic list would be usefull for this. Or i just mark empty array spots as invalid somehow [15:14] <ubitux> BBB: the patch doesn't apply [15:15] <BBB> oh [15:15] <BBB> well my tree changed a bit [15:15] <BBB> maybe we should merge more of my tree, let me rebase though on top of master first [15:25] <BBB> odd [15:25] <BBB> a straight cherrypick works fine here [15:25] <BBB> on origin/master [15:26] <BBB> ubitux: what's the apply error? [15:27] <ubitux> error: patch failed: libavcodec/vp9.c:348 [15:28] <ubitux> git am doesn't generate a conflict diff& so i don't know much, i should look [15:30] <BBB> I'll work on cleaning up my context-opts branch a bit so we can merge that, that would decrease my local changes quite a bit [15:30] <BBB> let me know if you need me to re-send this patch [15:33] <kurosu_> for anybody's information, the best I could come up using intrinsics for a recent dcadsp inline function is something generating 3 extra moves and is 1 cycle slower [15:34] <kurosu_> http://pastebin.com/aeTycSAz [15:36] <BBB> kurosu_: does the function _have_ to be inlined? [15:37] <kurosu_> well there's already yasm versions, but the cycle count is 23-27 depending on the processor, and the call generates 3-7 more cycles [15:38] <kurosu_> there's a gain, but the call causes a non-negligible loss here [15:38] <BBB> hm right [15:40] <BBB> why is this code block in that calling loop? [15:40] <BBB> if (!s->debug_flag & 0x01) { [15:40] <BBB> av_log(s->avctx, AV_LOG_DEBUG, [15:40] <BBB> "Stream with high frequencies VQ coding\n"); [15:40] <BBB> s->debug_flag |= 0x01; [15:40] <BBB> } [15:40] <BBB> also there's a bracket missing [15:40] <BBB> like if (!(.. & ..)) instead of if (!.. & ..) [15:41] <BBB> can't you put the whole loop in assembly? [15:41] <kurosu_> that's a predictable jump, I don't think it really matters [15:41] <kurosu_> http://pastebin.com/6yDnyyG3 <- the generated sequence [15:41] <kurosu_> oh [15:42] <kurosu_> I had never checked that before [15:42] <BBB> why not put the whole loop in assembly? [15:42] <BBB> then you don't need all this pain [15:43] <BBB> and I still think the if statement is missing brackets (not knowing anything about dca, but I can read C and that looks awfully weird) [15:43] <kurosu_> on the other hand, hfvq = s->high_freq_vq[k][l] makes it unlikely there's much sequentiality in the look up, so the inner loop will be small [15:44] <kurosu_> you're right, this code has nothing to do here [15:44] <kurosu_> I didn't see the loop ended so soon [15:44] <BBB> well you have to load one register with various (possible far-away) values for hfvq, yes [15:44] <BBB> but the rest is all l-incremental and could thus benefit from doing multiple at a time [15:49] <kurosu_> http://pastebin.com/q6SfVQGj <- that + dspize then [15:49] <kurosu_> need to go bye [15:51] <BBB> yeah (seeyou!) [16:48] <Daemon404> i think that with the amount of time trac has been down [16:48] <Daemon404> we really should have put a placeholder page... [16:48] <j-b> what is the issue? [16:48] <Daemon404> trac has been down for 3-4 days [16:48] <j-b> why? [16:48] <Daemon404> times out; its down for maitenenece [16:48] <Daemon404> or something [16:49] <j-b> I guessed so, but why is it not up again? [16:50] <Daemon404> still down for maintenence? [16:50] <Daemon404> i dont know. [16:50] <Daemon404> i dont think timing out for days on end is good for users [16:50] <beastd> Daemon404: you should see a maintenance page [16:51] <Daemon404> oh indeed its 503 now [16:51] <Daemon404> but 503 tends to just mean broken to me [16:51] <Daemon404> since in teh good old 1990s 503 really mean their perl cgi fucked up [16:51] <Daemon404> :D [16:51] <beastd> :) [16:52] <Daemon404> only thing worse was 500 [16:53] <beastd> got to go now. see you tomorrow [16:54] <Daemon404> bye [17:07] <cone-897> ffmpeg.git 03Janne Grunau 07master:0cffd6fff59f: x86: use the inline int8x8_fmul_int32 only if inline SSE2 is availbale [17:07] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:dd2b33034777: Merge commit '0cffd6fff59f192120dc93aa6c3cb8180f5506e3' [17:14] <cone-897> ffmpeg.git 03Vittorio Giovara 07master:b141c7b37eb5: h264: give numbers to nalus [17:14] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:4df9d9ca4f5a: Merge commit 'b141c7b37eb52aca41ac83738f159b63b9c09d5c' [17:30] <ubitux> BBB: if you want the patch to be applied before merging your branch, i can cherry-pick from your branch [17:30] <ubitux> BBB: do you want to do something in particular before the merge? [17:31] <cone-897> ffmpeg.git 03Janne Grunau 07master:5c1c6e82261b: dca: include dcadsp.h in {arm,x86}/dca.h for checkheaders [17:31] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:df98b36aa63c: Merge commit '5c1c6e82261b856214499b9fef3a08bf3ff6e0ae' [17:47] <J_Darnley> cbsrobot [17:48] <J_Darnley> Oops sorry. <rant>damn tiny backspace key!</rant> [18:17] <BBB> ubitux: just reword some commit msgs [18:18] <BBB> ubitux: but this one can be merged before it, it applies cleanly here, want a new pastebin of it on top of origin/master? [18:19] <ubitux> BBB: i can cherry-pick it from the branch, that's probably simpler [18:19] <ubitux> if you pushed it somewhere [18:20] <cone-897> ffmpeg.git 03Tim Walker 07master:c0c45188e56c: mlp: improve request_channel_layout behavior. [18:20] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:aedc10137de0: Merge commit 'c0c45188e56cfa3050bb39f8299025345b8a204c' [18:20] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:1a8050ad616c: avcodec/mlpdec: fix mulichannel output [18:20] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:bd35d58463f0: avcodec/mlp_parser: fix multichannel [18:20] <BBB> ubitux: no not yet :-p [18:22] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commits/vp9-context-opts [18:22] <BBB> ubitux: first commit on top of the main tree [18:23] <BBB> ubitux: and maybe the next one should be merged also, it aligns buffers a little better so big buffers are actually 16-byte aligned [18:25] <ubitux> ok [18:30] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:af63ea7078c8: vp9: re-allocate block buffers on uses_2pass change w/o size change. [18:30] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:7f0f47b3df9d: vp9: some variable re-arrangements for alignment. [18:30] <ubitux> BBB: tested and applied, thanks [18:30] <BBB> ty [18:30] <ubitux> BBB: also uploaded fuzzed10.ivf for you :) [18:31] <BBB> argh [18:31] <BBB> that bad? [18:31] <BBB> when does it get safer? [18:31] <ubitux> :) [18:31] <ubitux> it's an invalid read, with threading [18:32] <BBB> how long do you fuzz before you get anything? [18:32] <BBB> like millions per second, or a few seconds per one, or a few hours per one? [18:32] <ubitux> about 1 min [18:32] <BBB> :( [18:32] <ubitux> often less :p [18:33] <BBB> I was really expecting it to be harder by now [18:40] <ubitux> most of them are related to threading [18:41] <ubitux> that doesn't encourage me to do some mt work :D [18:47] <BBB> seems like we're not allocating a buffer correctly or so? [18:47] <ubitux> no idea :) [19:01] <cone-897> ffmpeg.git 03Tim Walker 07master:76a75c523cd3: lavr: mix front center channel as indicated in the ATSC A/52 specification. [19:01] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:b08f554fdc08: Merge commit '76a75c523cd3c63560185394a0a5cd7249db962a' [20:03] <cone-897> ffmpeg.git 03Kostya Shishkov 07master:cde7df25ef74: Mirillis FIC video decoder [20:03] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:0c4bf87b2961: Merge remote-tracking branch 'qatar/master' [21:31] <ubitux> saste: most of what is said about the lavfi tasks look outdated [21:31] <saste> oh i was on the wrong channel [21:31] <ubitux> but there is definitely stuff to do in lavfi& [21:32] <ubitux> saste: you don't want to mentor at all, or you don't want to mentor on lavfi? [21:32] <saste> so the question boils down to: who will mentor? [21:32] <saste> i don't want to mentor at all [21:32] <saste> i won't have time [21:32] <ubitux> ok [21:32] <saste> and i prefer working on ffmpeg myself if i'll have time [21:32] <saste> i'm not a gsoc enthusiast [21:33] <ubitux> i'm not either ;) [21:33] <ubitux> most of the stuff is about api though [21:33] <saste> ubitux, what filters do you think we are still missing? [21:34] <ubitux> slowmo [21:34] <ubitux> a useful denoiser [21:34] <ubitux> and speed improvements [21:35] <saste> i can act as backup mentor, but i won't be the main mentor [21:35] <ubitux> is what come to my mind with 1m of thinking [21:35] <wm4> port useful avisynth filters to lavfi [21:36] <saste> wm4: you going to mentor? [21:36] <wm4> probably not [21:36] <wm4> at least not for this topic [21:36] <saste> ubitux, so most likely, i'll kill the entry and that's all [21:36] <wm4> but it'd provide an endless source of work to do [21:37] <ubitux> saste: i think you can replace it with a slowmo filter :P [21:37] <BBB> omg something is asking hm questions on the ml [21:38] <saste> BBB: hm? [21:48] <BBB> hevc reference encoder [21:49] <BBB> ubitux: fixed [21:49] <BBB> that was mildly screwy, admittedly [21:50] <ubitux> BBB: appliable on master? [21:50] <ubitux> ('have it in your branch?) [21:50] <BBB> see ml [21:50] <BBB> I'll push, sec [21:51] <BBB> vp9-context-opts first patch [21:51] <BBB> now can that fuzz of yours please run for longer than a minute without giving me new warnings? this is very depressing [21:52] <BBB> it's like every line of code I write is screwy [21:52] <llogan> ubitux: like this? http://slowmovideo.granjow.net/index.html [21:52] <ubitux> llogan: yes :) [21:52] <llogan> i played with it a few days ago. was kind of fun. [21:52] <ubitux> we'll see ;) [21:53] <ubitux> BBB: and btw, those were with only sample we aren't even supposed to be able to decode :x [21:54] <ubitux> (the last 4 or so are based on the size change one) [21:58] <BBB> well, it's supposed to decode fine, just reconstruction is not fine, right? [21:58] <BBB> t [21:58] <BBB> we shouldn't show any cmdline errors about decoding failures; bitstream parsing should be fine [21:58] <BBB> (untested) [22:00] <ubitux> ok [22:00] <ubitux> anyway, let's start a new fuzzing session. [22:01] <BBB> ok [22:01] <ubitux> BBB: seems it last at least 1m this time ;) [22:01] <BBB> I'm still mildly concerned [22:04] <ubitux> it seems you'll have a bit more delay for the next one :) [22:04] <BBB> \o/ [22:04] <BBB> safety at last [22:04] <nevcairiel> now you jinxed it [22:04] <BBB> can you apply the previous one while you're at it? [22:05] <ubitux> you mean the fuzz10 fix? [22:05] <BBB> yeah [22:05] <ubitux> sure, i have it applied here while fuzzing [22:06] <BBB> ok [22:08] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:0c67864a37a5: vp9: don't allow retaining old segmentation maps after a size change. [22:09] <ubitux> BBB: you passed about 100k fuzzed tests [22:09] <ubitux> gonna try some random other source and parameters [22:12] <BBB> not bad [22:52] <BBB> ubitux: how far? [22:52] <ubitux> still fine [22:53] <ubitux> i got one crash but i'm not actually able to reproduce with the sample [22:53] <ubitux> it's allocating a lot of memory so that might be a false positive [22:55] <ubitux> i only get a ==1568== Warning: set address range perms: large range [0x13183080, 0x23b5649f) (undefined) [22:55] <ubitux> with valgrind [23:06] <BBB> ok new patches sent [23:06] <BBB> those are my last ones [23:06] <BBB> I have a local patch for intra pred simd which is half-done (I should really split it in 2 since some of it affects the c code also which should probably be separate) [23:06] <BBB> but it's not yet finished so I'll do that later [23:07] <BBB> after that I don't think I have any more big plans [23:35] <g3gg0> @michaelni: you there? [23:35] <michaelni> g3gg0, yes [23:36] <g3gg0> hi there. i amcontacting you regarding your SoC task "RGB Colorspace" [23:36] <g3gg0> Bayer RGB of course :) [23:37] <g3gg0> i am a developer in the Magic Lantern project, a widely used firmware addon to canon DSLRs and we recently introduced a video container for canon raw video [23:38] <michaelni> interresting [23:39] <g3gg0> maybe thats a good starting point for you to directly read raw video files [23:39] <g3gg0> the thread about the video plugin for cameras: http://www.magiclantern.fm/forum/index.php?topic=7122.0 [23:39] <michaelni> hmm, indeed, you should mail pross about this [23:40] <g3gg0> the file format explanation: https://docs.google.com/spreadsheet/ccc?key=0AgQ2MOkAZTFHdHJraTVTOEpmNEIwTV… [23:40] <g3gg0> ok [23:40] <michaelni> also dont hesitate to put me in CC if you like [23:41] <g3gg0> sure [23:41] <g3gg0> from your name i guess you are german, right? [23:41] <g3gg0> same for pross` [23:41] <g3gg0> ? [23:41] Action: michaelni is from austria [23:42] <BtbN> yay, the nvenc encoder is finished, now i have to find out if it works. [23:42] <g3gg0> ok [23:43] <michaelni> g3gg0, iam not sure peter speaks german [23:46] <Compn> yes i think ffmpeg needs more camera raw support, maybe steal from dcraw project :) [23:46] <Compn> pross knows about bayer :) [23:49] <g3gg0> yeah, but also in dcraw there are some inaccuracies iirc [23:49] <Compn> we all have bugs :) [23:49] <g3gg0> definitely [23:50] <g3gg0> about debayering, dcraw does quite a good job. [23:50] <g3gg0> thats a domain on its own [23:51] <g3gg0> i just asked because we have our own raw video file format that could be a superb demonstration workflow [23:52] <g3gg0> .mlv --> ffmpeg --> .mpeg [23:53] <Compn> sounds good, i didnt mean to bring up dcraw, its just on a very long todo list to be able to read all of those camera files :) [23:53] <Compn> if your raw file de/muxer is easily added to ffmpeg, that would be nice [23:54] <g3gg0> yeah. should be fairly simple [00:00] --- Sun Feb 9 2014

1 0

ffmpeg.log.20140208
by burek 09 Feb '14

09 Feb '14

[00:45] <luc4> Hello! I'm experiencing a little problem transcoding a video file. When trying to transcode I get "Frame rate very high for a muxer not efficiently supporting it." and "MB rate (324000000) > level limit (2073600)", and in fact the transcoding seems to never end. But ffprobe returns this for my stream "Stream #0:0(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 1280x720, 7569 kb/s, SAR 65536:65536 DAR 16:9, 22.70 fps, [00:45] <luc4> tbr, 90k tbn, 180k tbc (default)". Isn't this weird? [01:04] <luc4> Hello71: http://pastebin.kde.org/pjw0kigkc [01:07] <llogan> luc4: can ypu provide the input file? [01:07] <llogan> you can PM the link if it's something you don't want in public [01:12] <luc4> llogan: maybe I can cut it, let me try. [01:13] <llogan> isn't it just ~62MB? [01:18] <luc4> llogan: yes, but I can't provide it because the content cannot be disclosed unfortunately. I cut the first 5 seconds and I still see the same behavior. Can it be useful to reproduce the issue? [01:18] <luc4> llogan: assuming this is an issue... [01:22] <llogan> luc4: i'm guessing it may be useful. i can try to take a look at it later today. [01:23] <luc4> llogan: do you want a link to download or a bug report? [01:23] <llogan> just a link for now. i may not get to monkey with it much though until later [01:24] <luc4> llogan: no problem, just a second. [01:35] <llogan> if any of you here are students we are going to apply to Google Summer of Code this year if you're interested. [01:36] <klaxa> what exactly does that entail? is it a lot of time per week? [01:37] <llogan> it depends on the project you choose, your skill level, and your familiarity with FFmpeg, C, git, etc. [01:37] <llogan> also, students get money [01:38] <klaxa> that sounds really appealing [01:38] <llogan> http://www.google-melange.com/gsoc/homepage/google/gsoc2014 [01:38] <llogan> or course we, as a project, have to get accepted first [01:38] <llogan> s/or/of [01:38] <klaxa> the fear i have is that i will not be able to provide as much worktime as i would like [01:39] <llogan> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2014 [01:39] <klaxa> apparently by changing the study system to the bachelor-master thing, students have less spare time. i may have no comparison to how it was prior, but my personal projects get less and less of my time [01:40] <llogan> what's the "bachelor-master thing"? [01:40] <klaxa> i'm lacking the technical terms here... like you get a bachelor's degree first and then a master's degree [01:41] <klaxa> schedules are way tighter than they used to be [01:41] <klaxa> ah, i'm in germany [01:41] <klaxa> that is important to understand that i think [01:41] <llogan> oh. also i haven't attended higher education for 10 years or so. [01:42] <llogan> ...that decade was quicker than i expected. [01:42] <klaxa> heh [02:17] <shadowing> does anyone here have experience in re-encoding a ts file into another ts file? [02:17] <shadowing> I'm trying to re-encode a stream of TS segments individually, then concatenate them together [02:17] <shadowing> so far, I have the individual segment encoding done correctly [02:18] <shadowing> but when I concatenate them to see if they'll play correctly together [02:18] <shadowing> the video plays fine, but the audio has a noticeable stuttering at the segment boundaries [02:22] <shadowing> I'd guess that when I encode each TS segment, some excess audio is being cut off [02:22] <shadowing> anyone know of a way I can circumvent this? [02:23] <shadowing> here's a pastebin of what I ran: http://pastebin.com/QUcZuRjB [02:49] <kutemo> i have an issue over a filter that does not work if i resize [02:50] <kutemo> if i use this -> ffmpeg -i input.m2ts -map 0:0 -vf yadif=1 -vcodec libx264 output.mp4 [02:50] <kutemo> yadif works, but if i resize it does not [02:51] <kutemo> like so -> ffmpeg -i input.m2ts -map 0:0 -vf yadif=1 -vcodec libx264 -s 1280:720 output.mp4 [02:51] <kutemo> am i doing it wrong? why would it work if i don't resize though? [02:52] <kutemo> btw, this is on ubuntu x64, ffmpeg version 0.10.9 [03:01] <kutemo> the output messages are irrelevant, because they don't show any issues but the quality is what's different [03:01] <znf> kutemo, first of all, you're using "avconv" and not ffmpeg [03:02] <kutemo> i'll upload two images with the details [03:02] <znf> so try it with ffmpeg and not avconv [03:02] <llogan> kutemo: the output messages are usually relevant [03:02] <znf> as ffmpeg is at version 2.1.3, 0.10.9 sounds like avconv version ^^ [03:02] <llogan> although users have been resistant to providing the lately resulting in wasted time [03:02] <llogan> *them (as in the console outputs) [03:03] <llogan> and of course the console output indicates if you are actually using something from FFmpeg or not. [03:03] <llogan> and since this is #ffmpeg we can only support FFmpeg stuff here [03:03] <kutemo> znf, no i'm using ffmpeg. avconv is linked up to ffmpeg [03:04] <llogan> see the link [03:04] <kutemo> llogan, i did this a while ago and don't have the console ouputs anymore [03:04] <znf> kutemo, don't confuse avconv with libav [03:04] <znf> 0.10.9 is avconv version [03:05] <llogan> there was an old 0.10.9 ffmpeg. perhaps he is using the PPA from Jon S. [03:05] <kutemo> i remember the output messages and they were saying that both were using yadif [03:06] <llogan> if you're filtering then use the scale filter instead of -s. that way you can control when exactly you want to scale by placing it whever you want in the filtergraph [03:06] <llogan> -vf "yadif=1,scale=1280:-1" [03:07] <kutemo> this is what i'm using -> https://launchpad.net/~jon-severinsson/+archive/ffmpeg/+packages [03:07] <llogan> that's ffmpeg from FFmpeg, but it is old. [03:10] <kutemo> ok, thanks llogan i'll give that a try [03:25] <vl4kn0> Hi, I was looking over the decoding examples in ffmpeg git repository and the decoding_encoding.c examples includes a note in video decoding example saying: http://fpaste.org/75431/91826278/ [03:26] <vl4kn0> Now, the example only shows example of stream based codecs, but where can I find any frame based codec decoding? What's the difference between frame based and stream based encoding? [03:26] <vl4kn0> decoding* [09:28] <SirCmpwn> so I had an idea [09:28] <SirCmpwn> I'd like to render subtitles out of a video, onto a transparent background [09:29] <SirCmpwn> I tried ffmpeg -i transparent.png -video_size 1920x1080 -vf "subtitles=output.ass" -to 00:01:34 test.mp4 [09:29] <SirCmpwn> but the resulting file is unplayable [09:43] <SirCmpwn> this works if transparent.png is already the right size: ffmpeg -y -loop 1 -i transparent.png -vf "scale=1920:1080" -c:v libx264 -pix_fmt yuv420p -to 00:01:34 -vf "ass=output.ass" test.mp4 [09:43] <SirCmpwn> so apparently -vf scale doesn't work on images? [10:07] <anshul> it works at my place [10:08] <anshul> can you try after combining both filter -vf "scale=1920:1080;ass=output.ass" [10:09] <anshul> some time sccaling fails when out pix fmt is different [10:10] <anshul> try first converting your image to yuv420p then do scaling, oviously it is an work around [11:22] <Spideru> MOrning [11:23] <Spideru> http://trac.ffmpeg.org/wiki is down [12:18] <niakpi> pyffmpeg won't import: "DLL load failed: specified module cannot be found" (Win32, Python26) [12:18] <niakpi> any suggestions? [12:18] <JEEB> that thing probably has nothing to do with the FFmpeg project itself :) [12:18] <JEEB> because as far as i know such wrapper isn't maintained by FFmpeg [12:18] <JEEB> and given that python version I'm guessing that wrapper is just old [12:19] <JEEB> there's been quite a few API changes during the years [12:20] <niakpi> http://code.google.com/p/pyffmpeg/ [12:20] <niakpi> It's a different team I think [12:20] <JEEB> yes, completely unrelated [12:20] <JEEB> OUCH [12:21] <JEEB> four years old [12:21] <JEEB> yes [12:21] <niakpi> I know [12:21] <JEEB> that is most definitely going to have to be brought up-to-date [12:21] <niakpi> you know any alternatives? [12:21] <JEEB> because APIs have changed [12:21] <JEEB> nope [12:21] <sacarasc> The latest alpha on that site is almost 3 years old. [12:21] <JEEB> https://github.com/tranx/pyffmpeg/branches [12:21] <JEEB> their repo says 4 years since last commit [12:21] <JEEB> :D [12:21] <sacarasc> Wow. [12:22] <niakpi> I need it for opencv VideoCapture [12:22] <niakpi> in pytho [12:22] <niakpi> 8python [12:54] <fschuetz> Hello. [12:55] <fschuetz> Does ffmpeg offer a way to play from a filedescriptor - for example from an incoming stream of data? [12:55] <barhom> So I know I can use ffmpeg to transcode into h264+aac inside a mpegts container and stream the output to a multicast address and then playback via VLC. That is no issue. I would like to do the same with webm, vp8/vorbis. What am I missing? Doesn't webm support sending the metadata every x packets like mpegts to playback can start at any point? [13:41] <Hello71> fschuetz: /dev/fd/0 [13:41] <Hello71> note that seeking may fail [13:41] <Hello71> actually, just - [13:42] <Hello71> some containers are not streamable, however [13:42] <Hello71> e.g. mp4 [13:45] <Spideru> Hi, I'm trying to load this page https://trac.ffmpeg.org/ but from yesterday is down [14:04] <Overdrive> Hi guys, so i searched the whole internet and i could not find a guide that matched ffmpeg.exe commands to C++ settings for x264 encoding settings. Do you know where I could find such a guide? [14:05] <Overdrive> For exampe i've seen that it is advised to set options like this now: av_opt_set(c->priv_data, "preset", "slow", 0);. But what does slow mean, and what are the other options that I can set in that way? Is there a list somewhere ? [14:06] <sacarasc> Overdrive: I'd point you to https://trac.ffmpeg.org/wiki/x264EncodingGuide, but it is currently down. [14:06] <Overdrive> I've seen references on more websites to it but it is down for at least one week. [14:22] <Overdrive> Ok so i managed to see the page using the wayback machine. I've seen references to flags2=+wpred+dct8x8. But in c there are no CODEC_FLAG2_ dct8x8 or anything simlar. [17:23] <zmuss> Hi, I need help with creating rtsp stream with ffserver. There is no sound. I'm using aac codec. This is my ffservers.conf file: http://pastebin.kde.org/pxcqnpgup [17:29] <marti____> hello? [17:30] <marti____> somebody knows why https://trac.ffmpeg.org is offline? [19:12] <juke> hi [19:13] <juke> i convert a stream to many images, is there a way to limit dest directory size ? [19:48] <juke> is there a way to manipulate ffmpeg via socket/telnet ? [20:09] <DeadSix27> is possible via ffmpeg, to have 2 2channel audio input, and map 1 of them to FR/FL/C and the other 2 to SR and SL? [20:32] <grkblood> im trying to set the chunk duration of my stream with `ffmpeg -i stream.mp3 -acodec libspeex -ar 8000 -ac 1 chunk_duration 10000 -f ogg pipe:1` and I'm getting the error Unable to find a suitable output format for 'chunk_duration'. how do I set this? [20:46] <YuGiOhJCJ> hello do you understand why I got an "ALSA buffer xrun" message and an audio desync when I am capturing with ffmpeg (474db7a696a34582ee655c07e5073a6702236be0)? [20:52] <ChocolateArmpits> grkblood, did you forget to put a dash before chunk_duration ? [20:53] <grkblood> no, there is no dash, not according to the docs anyways. [20:54] <grkblood> if I put a dash it doesnt recognize the command [20:57] <ChocolateArmpits> ok, is your build compiled with speex? [21:05] <grkblood> yep [21:09] <grkblood> it works without the chunk_duration paramater ChocolateArmpits [21:10] <grkblood> this will be used for live streaming so i need as little delay as possible and with the speex compression each chunk is about 5 seconds. so theres a 5 second delay [21:10] <grkblood> i need to decrease the chunk size/duration [21:12] <grkblood> and the wiki is down https://trac.ffmpeg.org/wiki/StreamingGuide#Latency [21:15] <ChocolateArmpits> google cache has that page [21:30] <saste> ubitux: ping [21:30] <ubitux> saste: pong [21:30] <saste> ubitux, same as yesterday [21:31] <ubitux> yes, i'll answer in a sec on -devel [21:31] <saste> let me know if I should remove the lavfi entry from the gsoc page [22:39] <YuGiOhJCJ> http://pastebin.com/d3Sd69hm [22:39] <llogan> YuGiOhJCJ: what player are you using? [22:40] <YuGiOhJCJ> VLC [22:41] <llogan> ffmpeg -y -f x11grab -framerate 15 -video_size 640x480 -i :0.0 -f alsa -i default -c:v libx264 -qp 0 -preset ultrafast -c:a copy out.mkv [22:42] <llogan> if that doesn't work then try capturing video and audio using two separate ffmpeg processes and muxing the resulting files together [22:42] <llogan> if it does work, then you can re-encode out.mkv (since it is lossless and therefore probably huge-ish) [22:44] Action: llogan leaves to replace alternator in shitty car [22:45] <YuGiOhJCJ> in fact it does not help but I found that the problem is that my current directory is an NFS filesystem that is slow [22:45] <YuGiOhJCJ> if I go to the /tmp directory then I don't get anymore the "ALSA buffer xrun" message [22:46] <YuGiOhJCJ> because it is now a normal ext4 filesystem (not NFS) [22:46] <YuGiOhJCJ> and it is faster [22:48] <YuGiOhJCJ> I got a similar problem when I am streaming on an external server (like twitch.tv) [22:48] <YuGiOhJCJ> the "ALSA buffer xrun" message is back again [22:49] <YuGiOhJCJ> and so my audio stream is out of sync [22:50] <YuGiOhJCJ> for streaming I am not sure that it is possible to capture using two separate ffmpeg processes... So is there an other solution for streaming ? [00:00] --- Sun Feb 9 2014

1 0