April 2014 - Ffmpeg-devel-irc

ffmpeg-devel.log.20140429
by burek 30 Apr '14

30 Apr '14

[00:34] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:68c3e6025fa0: Fix convertion typos [00:34] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:fed0acebade8: ffmpeg: print an error at the end if conversion failed [00:46] <cone-834> ffmpeg.git 03Hendrik Leppkes 07master:2fcef90bee98: dxva2_h264: set the correct ref frame index in the long slice struct [00:46] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:2548f8a237b1: Merge commit '2fcef90bee98bffeff1d95b7197738f50c450d86' [01:03] <cone-834> ffmpeg.git 03Hendrik Leppkes 07master:ed4b757177f9: dxva2_h264: add a workaround for old Intel GPUs [01:04] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:0f630b7b1244: Merge commit 'ed4b757177f9b563412cdbc8ee3405d82e10fc05' [01:06] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:b2b4afe8115f: hwaccel: fix dxva2 & vaapi loop filter parameters [01:06] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:9c6eef6f5fcf: Merge commit 'b2b4afe8115fe3c8b005d663610e5af06f110165' [01:30] <cone-834> ffmpeg.git 03Hendrik Leppkes 07master:35177ba77ff6: avconv: add support for DXVA2 decoding [01:30] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:c6eee3120a59: Merge commit '35177ba77ff60a8b8839783f57e44bcc4214507a' [01:55] <cone-834> ffmpeg.git 03Anton Khirnov 07master:a61c2115fb93: configure: rework dxva in avconv handling [01:55] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:21c7e99659be: Merge commit 'a61c2115fb936d50b8b0328d00562fe529a7c46a' [04:38] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:648f7a6ec5b3: ffmpeg_dxva2: fix mixing of declarations and statements [04:38] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:7c710764705a: avutil/log: fix memleak from 669a09fb372fa58ff913ebc326cb64bb3e8e7928 [04:38] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:ede411dd0395: avcodec/vc1_parser: fix use of uinitialized memory [07:12] <cone-834> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:6d953ae2c4a4: ffserver: do not ignore ff_socket_nonblock return [07:12] <cone-834> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:8baa5b32a59c: ffserver: do not ignore setsockopt return [07:12] <cone-834> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:e79bc6a88aab: ffserver: do not ignore send() return [07:12] <cone-834> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:898192e0299e: ffserver: do not ignore getsockname() return [07:12] <cone-834> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:5b881499a8e4: ffserver: do not ignore lseek() return [09:50] <ubitux> 09:23:17 <+smarter> BBB, lu_zero: someone made a "human readable translation" of the hevc spec: http://www.f265.org/f265/static/txt/h265_companion.html [09:50] <ubitux> (might interest some ppl here too) [10:59] <j-b> Morning [11:03] <iive> evening :) [13:40] <BBB> and yes there's indeed too many hevc encoders [13:40] <BBB> can someone do a quality comparison or make a list of reasons why you'd use/develop any one of them? [13:41] <BBB> seems hopeless atm [13:43] <mraulet> BBB ready for asm review? [13:44] <pross-au> BBB: why is it we have N encoders, and much smaller N decoders? [13:45] <mraulet> already 2 decoders :-) which I think is already too much [13:45] <mraulet> and 4 encoders [13:45] <JEEBsv> basically x265 is still way in the lead regarding features and proper rate control, and everything else then has other positive things, like f265 having zomg docs [13:46] <pross-au> hypothesis: nobody will pay for decoder [13:46] <smarter> the kvazaar developers are nice, but it's the only GPL one [13:46] <JEEBsv> yeah, the kvazaar folk are nice [13:48] <mraulet> pross-au: well it is an alternative to set top boxes at the moment so ... [13:58] <BBB> mraulet: yeah always [13:58] <BBB> pross-au: decoders aren't ... interesting [13:58] <BBB> pross-au: once ffmpeg absorbs one, the others die [13:58] <BBB> pross-au: encoders have a more elaborate life-cycle, so they're more interesting [13:58] <BBB> and yes the pay also helps/hurts [13:58] <BBB> I mean x264 did really well for themselves there [14:39] <Compn> hmm [14:40] <Compn> so the ffmpeg_*.c files dont really have copyright in them? we arent doing that anymore ? [14:40] <Compn> duplicated author copyrights ? [14:47] <Compn> i guess ffmpeg never did that, i was thinking of mplayer :) [14:55] <pross-au> when all decoders are done, ffmpeg can start to absorb encoders too [15:02] <Compn> ffmpeg has to absorb imagemagick and dcraw :) [15:04] <pross-au> ciao [15:22] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:6a0b5e34763c: avcodec/mpegvideo: fix null pointer dereference [15:53] <zidanne> hi again guys (: [15:54] <zidanne> in one of my implementations, ffmpeg resolves aac with mChannelsPerFrame = 2, in another implementation of mine mChannelsPerFrame = 1. I couldn't figure out what's causing it (: Do you have any ideas? (it basically only sees 1 channel instead of 2, which is wrong.) [15:55] <thardin> are they using the same version of ffmpeg? [15:59] <zidanne> Yes they are :-/ [16:00] <zidanne> : - | [16:00] <J_Darnley> : - \ [16:03] <zidanne> Since the channel number is incorrect, audio is like a cassette player which's battery is about to die (: [16:07] <Compn> different probe size ? [16:07] <Compn> but thats strange it shouldnt affect that [16:07] <nevcairiel> sounds like you may be missing extradata or other initialization data [16:07] <thardin> diff all structs you send into libav* [16:26] <cone-701> ffmpeg.git 03Enrique Arizón Benito 07master:5c08ae4f3728: segment: Add an option to prepend a string to the list entries [16:26] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:fd601ba6b1c6: Merge commit '5c08ae4f37281441188447cd04dcaf7cd7ce031f' [16:28] <zidanne> I check channel_layout and it unfortunately AV_CH_LAYOUT_MONO. I checked probe size they are same, I made it big too but nothing changed. When I manually assuma the channel number is 2, audio plays perfectly. But if I leave it to pcodecctx->mChannelsPerFrame (which is 1), audio slows down as expected [16:28] <zidanne> so, I must be doing something that breaks ffmpeg and ffmpeg detect wrong number of channels [16:38] <zidanne> I found something [16:38] <zidanne> pCodecCtx->channels = 1, but, decoded_frame.channels = 2, is this normal? [16:39] <nevcairiel> ideally you should always use the frame properties, things like this can happen, although its probably a bug when they do [16:43] <J_Darnley> You said this was AAC. Is the the kind of AAC with its "strange" stereo encoding mode? [16:44] <zidanne> J_Darnley: rtmp://stream.n2.noc.com.tr/live/radyoa.stream [16:46] <J_Darnley> Hmm, ffprobe doesn't say. [16:56] <zidanne> it seems like it is AAC+SBR [16:56] <nevcairiel> SBR only messes with sample rate, not number of channels [17:03] <zidanne> ok guys, you are right. I think I found the problem. I was checking codecCtx->channels before the first avcodec_decode_audio4. When I debug, after the decoding it updates codecCtx->channels to 2 correctly. [17:06] <cone-701> ffmpeg.git 03Luca Barbato 07master:5a70a783f049: hls: Add an option to prepend a baseurl to the playlist entries [17:06] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:217f6c53e5c2: Merge commit '5a70a783f04919514efec7751d710b64d8975fd7' [17:10] <plepere> openHEVC patch submitted. please be gentle. :) [18:47] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:f694ca7ca7a6: avcodec/tiff: support 4:2:2 and 4:1:1 YCbCr [18:53] <kurosu> plepere, do you have a rough estimate of the speedup that the new handling of uni/bidir brings? [19:04] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:4506ed336ff7: avformat/img2_alias_pix: fix 2 unused variable warnings [19:43] <cone-701> ffmpeg.git 03Nicolas George 07master:b804eb4323a0: lavu/hash: add hash_final helpers. [19:43] <cone-701> ffmpeg.git 03Nicolas George 07master:3926a30b58f6: tools/ffhash: use av_hash_final_hex(). [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:73c4b6ce4b39: tools/ffhash: implement base64 output. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:e419e29e1c9a: lavc/codec_desc: add separation comment. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:fa7bc7ed8b21: lavc: add codec descriptors for deprecated ids. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:892e2c2ad8ea: lavc: add codec descriptors for TTF and OTF. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:6ea1196673b7: lavc: add AV_CODEC_ID_BIN_DATA. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:1bf63964985e: lavc: add a mime_types field to codec descriptors. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:70beebe35764: lavc: minor bump and APIchanges for AVCodecDescriptor.mime_types. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:c9212abf95be: lavf/matroska: add "binary" pseudo-MIME type. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:43ca94a63373: ffprobe: use the codec descriptor if no decoder was found. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:e973cf04f6bf: lavf/concatdec: use a structure for each stream. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:c27939d87103: lavf/concatdec: check match_streams() return value. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:b24d6c53037a: lavf/concatdec: always do stream matching. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:9d24a536a3d2: lavf/concatdec: reindent after last commit. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:50ed6e3ce635: lavf/concatdec: implement automatic conversions. [19:44] <cone-701> ffmpeg.git 03Nicolas George 07master:41334fcab41f: lavfi/drawtext: allow to format pts as HH:MM:SS.mmm. [19:44] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:03b88f6b3933: Merge remote-tracking branch 'cigaes/master' [21:51] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:c31ad87bc664: avformat/xwma: use NULL instead of 0 for pointers [21:51] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:cf4dbe9affa1: avformat/xwma: improve error codes [21:51] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:375a0c03a9a4: avformat/xwma: fix memleak of dpds_table [22:15] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:978c193d47c0: cmdutils: omit deprecated codec ids in help output [22:27] <llogan> i'm going to be gone for about 2 weeks but i'll still be able to deal with mailing list queue [23:14] <jamrial> michaelni: ever since fed0acebade8d27c428da5cad483cd6a5b64b354 if you run ffmpeg alone with no options it will show "conversion failed" [23:14] <jamrial> is that intended? [23:16] <cone-701> ffmpeg.git 03gcocherel 07master:2eddf3a6efd8: avcodec/hevc: fix no output of prior pics and pic output flags(cherry picked from commit e99b96dff1d76d74cb5633aa9702828d863050e2) [23:17] <michaelni> hmm [00:00] --- Wed Apr 30 2014

1 0

ffmpeg.log.20140429
by burek 30 Apr '14

30 Apr '14

[01:59] <kode54> ah [01:59] <kode54> I was using ffmpeg 2.2.1 built against libvpx 1.3.0 [10:50] <djdduty> hallo! I probably have a peculiar problem.... I am trying to use ffmpeg on windowns to compile images into a timelapse, but the images are name things like screen_11398474789.43.png and they don't increment in any way, how can I just add all images? [10:50] <djdduty> *.png type of thing doesn't work. [10:56] <djdduty> so I group renamed them and now they are img (n).png [10:56] <djdduty> still cannot add it with img (%05d).png [11:07] <brontosaurusrex> djdduty, hold on [11:08] <brontosaurusrex> %05d.png < should work [11:09] <brontosaurusrex> ffmpeg -f image2 -i img%05d.png ... < example [11:10] <brontosaurusrex> (looking at my script, which is doing temporary soft-links before feeding those to ffmpeg (counter=$(printf %05d $x); ln -s "$i" /tmp/img"$counter"."$ext"; x=$(($x+1));)) [11:11] <djdduty> I am running ffmpeg -i "%05d.png" timelapse.mp4 now, and I did rename the pictures so they are all 1.png, 2.png etc now [11:12] <brontosaurusrex> that would be %1d.png i imagine [11:12] <djdduty> brontosaurusrex: it goes up to 16664.png [11:13] <brontosaurusrex> djdduty, let me google on the %d formating .... [11:14] <brontosaurusrex> try %5d [11:14] <djdduty> did already [11:14] <brontosaurusrex> http://www.promotic.eu/en/pmdoc/Appendix/FormatStringSpec.htm < reading this [11:16] <brontosaurusrex> how about only %d ? [11:16] <djdduty> brontosaurusrex: did that as well :( [11:17] <djdduty> wait, even typing in 1.png it doesn't find it [11:17] <djdduty> dir reveals I am in the right path etc [11:17] <djdduty> gah [11:17] <brontosaurusrex> ffmpeg -f image2 -i 1.png ... ? [11:19] <djdduty> brontosaurusrex: wait I got it [11:19] <djdduty> moved all the images to ffmpeg bin directory :DDD [11:20] <djdduty> the prompt bat script ffmpeg comes with must be botching it [11:20] <brontosaurusrex> djdduty, what os are you on? [11:20] <djdduty> windows [11:20] <brontosaurusrex> oh [11:20] <brontosaurusrex> so what was the correct option? %d only? [11:23] <djdduty> that's what I did yeah, but I didn't really try the others here [11:23] <djdduty> it is only working now because I just put all the images in the bin dir and ran it there [11:24] <djdduty> it's on image 4600 now. [12:45] <termos> when using yadif I get half the framerate, so my video is playing in slow motion! I see from http://avisynth.org.ru/yadif/yadif.html that there's a double framerate option but this does not exist in ffmpeg. [12:45] <termos> Do I need to do setpts=0.5*PTS as my next filter? [12:48] <termos> it's not really an ffmpeg command as I'm linking against libffmpeg and using the API, but the filtering command is: yadif=0:-1:0 [12:51] <c_14> Are you sure the source is interlaced? you might also want to try yadif=1:-1:0 [13:39] <lkiesow> Question about the ffmpeg parameters: Is there a difference between -ab X and -b:a X? And which expression is preferred nowadays? My feeling is that -b:a is more consitent to the other options like -c:[av] [13:40] <JEEBsv> lkiesow: yeah the x:y settings are newer and more consistent/preferred right now [13:40] <lkiesow> thought so, thanks [15:52] <Lumbendil> hey [16:09] <superc2_> ffmpeg: Server error: call to function _checkbw failed [16:13] <Lumbendil> if I tell ffmpeg to encode a 200k source to 600k, it'll yeild a file 3 times bigger, even if that doesn't increase image quality. Is there any way to prevent such behaviour? [16:13] <klaxa> superc2_: provide more information please [16:13] <klaxa> Lumbendil: not really since you specify the bitrate in a hard way [16:13] <klaxa> it is also pretty much the expected behavior [16:14] <klaxa> you can use different quality control methods [16:14] <superc2_> What I'm doing is " ffmpeg -i rtmp://localhost/live/mp4:webCam.f4v rtmp://localhost/live/test" [16:14] <Lumbendil> for instance? Quite newby to this [16:14] <klaxa> that depends on the codec you are using [16:14] <Lumbendil> h264 [16:15] <Lumbendil> with libx264 [16:15] <klaxa> see: https://trac.ffmpeg.org/wiki/x264EncodingGuide [16:15] <Lumbendil> ty [16:15] <superc2_> so I'm trying to restream this mp4:webcam.f4v stream to 'test' stream on same host [16:15] <superc2_> and then I get this error message [16:15] <klaxa> phew no idea, what's your server setup? [16:16] <superc2_> in the meanwhile I installed crtmpserver because I didn't get ffserver running [16:17] <superc2_> so basically I'm able to stream from a flash app to the server and from there back to the flash app an see the video [16:17] <superc2_> now I need to connect the stream and restream it to another [16:18] <superc2_> and as I understand I need ffmpeg for this [16:18] <Lumbendil> klaxa: from what I'm reading, if I want a certain max bitrate, but to give up to a certain quality, I'd use -crf X -maxrate Y, right? :) [16:19] <klaxa> pretty much [16:19] <klaxa> if the desired quality would require more bitrate than Y, quality should be degraded in order to stay below the maxrate limit [16:21] <klaxa> ehh... documentation for crtmpserver is pretty sparse [16:24] <superc2_> jep... actually there is no documentation [16:24] <superc2_> but it works [16:36] <Lumbendil> klaxa: do you know if with ffprobe there is any way to get the crf? [16:36] <klaxa> unless it is written in the metadata there is no way to obtain crf value [16:36] <klaxa> i don't know whether ffprobe prints it, mediainfo prints it if it exists [17:45] <Lumbendil> klaxa: I'm checking the mediainfo output, if it existed, it'd be shown somewhere like "crf", right? [17:46] <Lumbendil> I guess on "Encoding settings" [21:35] <nineteenninetyni> Hi. [21:36] <nineteenninetyni> How can I know the usage of each enconder in Ffmpeg? I know the supported codecs by putting -encoders. [21:36] <c_14> ffmpeg -h encoder=$encoder ? [21:38] <nineteenninetyni> Thanks! [23:21] <Lokie> hello, i got 2 questions that a quick search in the site & google didn't solve. Is it possible to rip the font from a video and use it for the encode to avoid having ffmpeg fall back to Arial? [23:22] <Lokie> also is there a way to encode without specifying target bitrate? like letting ffmpeg choose it? [23:22] <c_14> For the second question, you can use -crf. [23:22] <sacarasc> Assuming Matroska, you can use mkvextract to take out the font. [23:23] <Lokie> it's in a cli linux box [23:23] <Lokie> c_14 as far as i see in the encoding guide it still specifies target bitrate [23:23] <sacarasc> That changes neither of our answers. [23:25] <c_14> Lokie: you can also use: ffmpeg -dump_attachment:t "" -i INPUT [23:25] <c_14> assuming the fonts are attached to the video [23:25] <sacarasc> I did not know you could do that. :O [23:25] <sacarasc> c_14 educates us all. [23:26] <c_14> Lokie: you have to define a bitrate _somewhere_, you can't have a video file without one. [23:27] <sacarasc> You need one form of rate control, yeah, but it doesn't have to be a target bitrate. [23:27] <Lokie> i was thinking something along the lines ffmpeg looks at the size of the source and creates the new file with a bitrate that should make the target file similar [23:28] <Lokie> something like megui can do [23:28] <Lokie> not really important since i am sure a bit of googling will show me some tool that can tell me what bitrate the source is using [23:29] <c_14> ffprobe will give you the total bitrate and you can subtract the bitrate of the audio from that [23:29] <sacarasc> -crf between 19 and 22 will usually give you a ~transparent file. [23:30] <Lokie> i am not sure i follow you sacarasc. Wouldn't i still need to specify the bitrate? what do you mean with transparent? [23:31] <Lokie> thx c_14. for the dump_attachment there seems to be limited documentation [23:31] <sacarasc> Looking pretty much like the original. [23:31] <sacarasc> And no, you'd not have to specify a bit rate. [23:31] <Lokie> so ffmpeg -i input.mp4 -c:v libvpx -crf 10 -b:v -c:a libvorbis output.webm [23:31] <Lokie> copying the example command from the guide and removing the bitrate value [23:31] <sacarasc> Oh, you're using vp8. [23:32] <Lokie> yes i failed to mention that [23:33] <c_14> With vp8 it really depends, I usually set the crf to 4 and also set a bitrate to get it to look decent. But to your specific command: If you don't want to explicitly set a bitrate, don't type the -b:v or else ffmpeg will error [23:34] <Lokie> and it should be around the same with the values sacarasc said [23:34] <Lokie> will try it out [23:34] <Lokie> same size* [23:34] <sacarasc> I don't know the range that VPX uses, mine was for x264. [23:34] <Lokie> By default the CRF value can be from 463, and 10 is a good starting point. Low [23:35] <Lokie> lower = better [23:35] <Lokie> i will have to try a few values [23:35] <Lokie> still good to know [23:36] <Lokie> ffmpeg -dump_attachment:t "" -i out.mkv <-- out.mkv is what it should check for the attachments [23:36] <Lokie> and it dumps them in the current dir? [23:37] <c_14> ye, if your input is called out.mkv that is [23:38] <Lokie> i get hit with "At least one output file must be specified" [23:38] <c_14> It still works though... [23:38] <c_14> Check your cwd. [23:39] <c_14> That confused me for a while as well. [23:39] <Lokie> both the dir i used the command from and the dir that the file resides in [23:39] <Lokie> don't contain anything new [23:39] <Lokie> wait [23:41] <Lokie> i don't see anything but might be that the source is not the best choice being an avi (ignoring the fact that the subs there are hardsubs it should spit out the video and audio streams?) [23:41] <Lokie> will try tomorrow, thank you both for your help! [23:42] <c_14> Nah, it'll only spit out things specifically labeled as attachments or "codec extradata". [23:42] <c_14> Also, not every format supports them. [23:43] <c_14> Check with ffprobe to see if there are attachments before trying to extract them. [23:44] <Lokie> Stream #0:0: Video: msmpeg4v3 (DIV3 / 0x33564944), yuv420p, 640x352, 1569 kb/s, 23.98 tbr, 23.98 tbn, 23.98 tbc [23:44] <Lokie> Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s [23:44] <Lokie> so i am guessing nothing to be extracted [23:44] <Lokie> will try with a proper mkv tomorrow [23:45] <c_14> It should look something like this: http://ix.io/c0t [23:46] <Lokie> cheers [23:47] <c_14> \o [00:00] --- Wed Apr 30 2014

1 0

ffmpeg-devel.log.20140428
by burek 29 Apr '14

29 Apr '14

[00:30] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:4260ed462b4c: avcodec/h264_cabac: fix indention [00:31] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:e31727bd53fc: avcodec/mjpegdec: make type of shift unsigned to avoid undefined behavior [00:31] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:d80e7ba9b7de: ffmpeg_filter: make *jpeg_formats static const [02:32] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:2cf514354bbe: avcodec/mpeg12enc: increase declared size of block function argument [04:57] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:18af0ce62da3: avfilter/graphdump: Fix pointer to local outside scope [08:24] <anshul_> cehoyos, why is it hard to believe? [10:03] <j-b> good morning [13:38] <BBB> hi j-b [14:00] <mraulet> michaelni: how to update sequences on fate? [14:26] <j-b> hello BBB [14:26] <BBB> \o/ [14:27] <BBB> so, when's ny going to welcome you, dear sir? [14:28] <BBB> oh work, gtg, later [14:40] <michaelni> mraulet, make fate-rsync [14:40] <mraulet> no in the opposite [14:40] <mraulet> I have new sequences [14:41] <mraulet> and some that I need to remove [14:41] <nevcairiel> if those removed ones were used in tests before, they should remain on the fate system so that older tests in eg. release branches remain functional [14:42] <michaelni> to add new ones, post a link to what should be added and a path to where exactly it should be added [14:43] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/df245c6c1a5f21ecf646f500c20c5fcd9… [14:43] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/afa7c81ed4ad312d6a4266c2194392923… [14:44] <mraulet> I can give you a link to those sequences [14:44] <mraulet> nevcariel: if they have been removed from jct-vc, there is good reasons [14:45] <mraulet> so I suppose fate should do the same [14:45] <nevcairiel> well fact remains that old release branches would then fail as they are missing the samples [14:45] <nevcairiel> if there is a good enough reason might as well patch the release fate tests [14:46] <michaelni> removial is not possible [14:46] <mraulet> oh pfiou [14:46] <michaelni> it would break git bisect [14:46] <nevcairiel> that too [14:46] <nevcairiel> you can stop testing them of course [14:46] <nevcairiel> just the samples should stay [14:46] <mraulet> ah ok [14:46] <mraulet> this looks better [14:53] <smarter> hey mraulet [14:54] <smarter> some of these streams are already in FATE, like tests/ref/fate/hevc-conformance-LS_B_ORANGE_4 [14:57] <smarter> I think only bitstreams which are less than 3 months old haven't been added yet [14:58] <mraulet> smarter: I notice the issue for Orange_4 [14:58] <smarter> mraulet: by the way, did you implement pic_output_flag? It's needed for OPFLAG_B_Qualcomm_1 and OPFLAG_C_Qualcomm_1 [14:58] <mraulet> yes [14:58] <smarter> ah cool [14:59] <mraulet> it is part of one patch here [14:59] <mraulet> I have not added bumping process since we cannot support it [14:59] <smarter> I don't see pic_output_flag support in the commits you linked [15:00] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/2cf2cfdd10cf67090bb9ab9c7bcda8a60… [15:01] <smarter> okay, so if you have other changes like these, they should be merged first before adding the new streams to FATE [15:01] <mraulet> yes [15:03] <mraulet> we will redo the patches and provide a link to the new sequences [15:56] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:4394f82f5258: avformat/utils: add gif to tb_unreliable() [15:56] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:1f249d2ca725: avformat/utils: prevent r frame rate from being set larger than 1/tb [16:48] <cone-834> ffmpeg.git 03Anton Khirnov 07master:1eb57e1d9b59: lavc: eliminate tb_unreliable() [16:48] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:502a8f56b9f7: Merge commit '1eb57e1d9b59db0aa63348c21bf3290bd3f5efcb' [16:48] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:34e7d3c3681a: avformat/utils: Ensure that average fps is probed if requested by the user even if tb_unreliable() is 0 [16:50] <ubitux> michaelni: about tb_unreliable i might have a clue of why it's been applied [16:50] <michaelni> yes? [16:50] <ubitux> i'll paste a log in a moment [16:50] <ubitux> need to dig that again [16:55] <ubitux> michaelni: http://b.pkh.me/tb_unreliable.log [16:56] <ubitux> this was just before the patch was sent, i guess it's related [17:10] <michaelni> thx [17:10] <michaelni> also if anyone has any testcases where libav provides better fps values by default, please ping me [17:13] <nevcairiel> elenril with his obsession with vfr, not considering the 99% of all cases which are not :p [17:15] <Daemon404> that value is probably lower with the advent of smartphones [17:15] <Daemon404> which all capture vfr [17:16] <nevcairiel> mine doesnt [17:16] <Daemon404> all apple ones do [17:16] <Daemon404> and many android [17:16] <Daemon404> (iirc) [17:16] <nevcairiel> i havent had an android phone which did vfr [17:16] <nevcairiel> either 30 or 60, but not variable [17:16] <Daemon404> maybe its just apple [17:19] <JEEB> nah, at least two of my android phones do VFR [17:20] <JEEB> although mostly in cases when they can't keep up [17:21] <nevcairiel> does it really go vfr and slow down to a lower fps, or just skip a frame here and there? [17:22] <JEEB> skipping methinks, it still ends up being VFR timestamp-wise though [17:24] <nevcairiel> well sure, but the target pretty much remains say 30 fps, it just couldn't keep up and leaves a few "holes", all frames which did make it still fit the 30 fps timestamp chain .. with holes [17:54] <ubitux> michaelni: i don't understand what this tb change for gif fixes [17:54] <ubitux> can you elaborate? [17:55] <ubitux> current demuxer set a 1/100 tb, after your change the samples go from 1/100 to 1/10 (which seems enough to represent every ts, right) [17:56] <michaelni> r_frame_rate before was 100 after the change its 10 [17:57] <michaelni> 10 is more "tighter" [17:57] <michaelni> fewer duplicated frames with cfr output [17:58] <michaelni> actually none id assume [17:59] <ubitux> ah ok [18:00] <ubitux> and so if at some point in the gif you get a ts making use of the 1/100 tb, this won't be changed to 1/10 right? [18:00] <michaelni> if its within the frames that are probed, yes [18:00] <ubitux> mmh ok [18:01] <michaelni> a user app can always use the timebase instead of r_frame_rate [18:01] <michaelni> if it wants to be sure that all timestamps can be represented excatly [18:01] <ubitux> ok [18:02] <Daemon404> correction: They *should* be using the timebase [18:03] <michaelni> yes, but sometimes they just cannot, like for cfr output with a 1/1000000 tb [18:59] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:a215b158152e: avformat/utils: Set the average frame rate from the r_frame_rate if the stream appears to be cfr [19:04] <Daemon404> that seems like it could be a horrible idea... [19:06] <michaelni> Daemon404, why? [19:06] <Daemon404> because it is using a heuristic [19:06] <michaelni> what ? [19:07] <Daemon404> a heuristic to detemrine if it is cfr [19:08] <michaelni> avg_frame_rate is purely a heuristical guess [19:08] <Daemon404> are you saying heuristic to detemrine if it is cfr [19:08] <Daemon404> er [19:08] <Daemon404> fail [19:08] <Daemon404> damn tty [19:08] <Daemon404> what i meant: [19:09] <Daemon404> are you saying avg_frame_rate is not the avg frame rate? [19:09] <Daemon404> i.e. based on the average [19:09] <nevcairiel> for most formats you wouldn't know the absolute average until you're done reading the file [19:09] <michaelni> nevcairiel, yes [19:09] <nevcairiel> so instead, you guess [19:09] <Daemon404> right [19:10] Action: Daemon404 should fasttrack his plans to move to his own fps code [19:10] <michaelni> yes and the new code isnt doing anything more evil than that [19:10] <Daemon404> based off of preindexing the file [19:10] <nevcairiel> I wish i could afford pre-indexing a file [19:10] <nevcairiel> but alas, yay playback [19:10] <Daemon404> yeah [19:11] <nevcairiel> to be fair i dont really worry about the fps value much either way [19:11] <nevcairiel> hoping for timestamps [19:11] <Daemon404> matters to me :P [19:11] <nevcairiel> that reminds me that i've had a few files recently which had screwed up h264 timestamps, i wanted to check out what happened to them... [19:12] <nevcairiel> (ts files) [19:13] <michaelni> Daemon404, do you have files that produce a bad fps value ? [19:13] <michaelni> if so i would be interrested and will take a look at them later [19:13] <Daemon404> ltos, but not indexed for me to find in any meaningful way [19:13] <Daemon404> lots* [19:13] <Daemon404> mostly because an average over a duration is not inherently useful [19:13] <Daemon404> for certain sorts of vfr files [19:14] Action: Daemon404 's code uses other fancy like LCM and stuff over the preindexed file [19:15] <michaelni> is the r_frame_rate bad too ? [19:15] <michaelni> also either way, id like to see the files [19:15] <Daemon404> on some files yes [19:15] <Daemon404> choosing a "good" framerate requires preindexing IMO [19:16] <Daemon404> simple stuff liek checking for ridiculous timestamp delta outliers [19:16] <Daemon404> as an example. [19:16] <michaelni> yes, you need preindexing if you want a perfect value in all cases [19:16] <Daemon404> yep [19:16] <Daemon404> thats what im currently doing [19:17] <michaelni> still iam hoping to be able to improve the non preindex code if possible [19:17] <michaelni> because preindex is not always an option [19:17] <michaelni> not an option for some people / cases [19:17] <Daemon404> yes [19:17] <Daemon404> like nevcairiel [19:18] <nevcairiel> havent had much complaints recently anymore though about bad values [19:18] <Daemon404> for the non-preindexed version [19:18] <Daemon404> it may help if the file can be accurately (or semi accurately) seeked [19:18] <Daemon404> i.e. use a few windows for analysis [19:19] <Daemon404> not sure if ffmpeg does this currently [19:19] <nevcairiel> i think it just analyses a window at the start of the file [19:19] <Daemon404> yeah thats what i assumed [19:19] <Daemon404> i have a lot of files with e.g. the ending credits are 30fps [19:19] <Daemon404> rest is 24 [19:20] <michaelni> need to leave, ill be back in 30min or so, please provide some failing files (i dont have any AFAIK) [19:20] <Daemon404> should be relatively easy to create one [19:21] <Daemon404> ill try in a bit [19:21] <nevcairiel> personally, for my own goals and whatnot, i would prefer 24 fps as the information for such a file, who cares if the ending credits stutter then :p [19:22] <Daemon404> well yes [19:22] <Daemon404> consider a case where analyse duration is all 24 fps (e.g. an opening credits) [19:22] <Daemon404> but the rest of teh file is 3 hrs of 30fps [19:23] <Daemon404> you wanna be a bit smarter if converting to cfr [19:24] <nevcairiel> i guess, but its all more heuristics, and slows down opening significantly [19:27] <nevcairiel> we should all just switch to mp4 [19:27] <nevcairiel> where every timestamp ever is in the header [19:39] <wm4> such a stupid format [19:40] <nevcairiel> i really like that about mp4, decoupling all metadata from actual media data [19:44] <wm4> I think well designed media formats should be naturally streamable, and some properties of mp4 make this hard [19:45] <Daemon404> [18:27] <+nevcairiel> where every timestamp ever is in the header [19:45] <Daemon404> or more usually: the tail [19:46] <Plorkyeran> naturally streamable and easy to seek in are unfortunately somewhat mutually exclusive [19:47] <Daemon404> and then you have ogg [19:47] <Daemon404> which is neither [19:47] <wm4> Daemon404: but is used for both anyway! [19:47] <wm4> (why wasn't ogg killed yet?) [19:48] <Daemon404> because xiph uses it for every new thng [19:48] <Daemon404> daala is using ogg too [19:48] <Daemon404> hell, their ssim tool has a harp dep on libogg [19:48] <Daemon404> hard* [19:49] <nevcairiel> Daemon404: well head or tail, but in one dedicated easy-to-find block! [19:50] <Daemon404> and if its not there [19:50] <Daemon404> youre fucked [19:50] <wm4> at least they should attempt to make its design cleaner (i.e. full redesign + keep name/file ext.) [19:50] <Daemon404> forgot the last few kb of the time? [19:50] <Daemon404> hahahaHAHAHAHAHA enjoy [19:50] <Daemon404> of the file* [19:50] <nevcairiel> well, but then the whole file doesn't work, and you dont have to worry about fps [19:50] <Daemon404> ive been left with 5 gb mp4s missing a few kb at the end [19:50] <Daemon404> rendered entirely useless [19:50] <Daemon404> great format [19:51] <nevcairiel> i suppose its easier to lose a few kbs at the end than at the start [19:51] <Plorkyeran> should make a format where the contents are encrypted using the hash of the file as the key [19:52] <Plorkyeran> to ensure that a single corrupted bit stops you from opening the file [19:52] <Plorkyeran> to one-up mp4 [19:52] <Daemon404> or just make the fire entirely bitpacked [20:23] <cone-834> ffmpeg.git 03James Almer 07master:096de451b0f9: configure: add support for new CPUs [20:24] <michaelni> smarter, mraulet, do you know if " [FFmpeg-devel] [PATCH] avcodec/hevc_cabac: decrease CABAC_MAX_BIN" is ok ? [20:29] <smarter> michaelni: I think it should be ok [20:30] <michaelni> smarter, ok thx [20:30] <smarter> michaelni: it seems that CABAC_MAX_BIN could be 32, since the checks are always k < CABAC_MAX_BIN [20:30] <smarter> mraulet: do you see anything wrong with this change: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-April/157091.html ? [20:31] <michaelni> smarter, i think with 32 it will shift into the sign bit somewhere [20:35] <michaelni> ff_hevc_cu_qp_delta_abs could be changed to unsigned but mvd_decode() needs signed output [20:36] <smarter> michaelni: ah you're right [20:36] <smarter> so the patch should be fine [20:38] <kurosu> what's that max for? max length of a specific syntax element, eg mvd ? [20:38] <kurosu> s/a specific/any, actually [20:41] <kurosu> seems so [20:43] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:812066835189: avcodec/hevc_cabac: decrease CABAC_MAX_BIN [21:19] <mraulet> openhevc already have it to 32bits [22:35] <wm4> michaelni: note that libav just broke the build with the dxva patch, so maybe you shouldn't merge that yet [00:00] --- Tue Apr 29 2014

1 0

ffmpeg.log.20140428
by burek 29 Apr '14

29 Apr '14

[01:00] <ac_slater> hey guys, I just got done reading a boat load of MISB standard documentation. They REALLY like MPEG2TS for a container that can hold audio, video, and generic data. Question is, I don't see any libavcodec examples for MPEG2TS muxing. Where should I start? [01:02] <ac_slater> I'll ask in ffmpeg-devel [01:02] <ac_slater> oh nevermind, their topic says I should ask here. Fair enough ;) [02:16] <The_Ball> I'm trying to find out if a security camera puts additional information (like motion detection triggers) in the transport stream. It's a RTSP transport which ffplay reports as containing two streams: Stream #0:0, 28, 1/90000: Video: h264 (Baseline), yuv420p(tv), 2048x1536 [SAR 1:1 DAR 4:3], 1/180000, 15.17 tbr, 90k tbn, 180k tbc and Stream #0:1, 1, 1/90000: Data: none, 0/1. Is there a way I can dump anything that is being sent in the data stream? [02:16] <The_Ball> Or could there be KLV fields hidden in the h264 stream perhaps. Would -loglevel debug show any embedded KLVs? [08:51] <road|runner> hi, i uses sockso streaming server and would like transcode on the fly flac to mp3. to do this i uses ffmpeg -i file.flac -vn -f mp3 -ab 320k -. in most cases this works well but some jobs are truncated. no idea why. when using same construct in windows cmd and pipe the output diretcly to a player ffmpeg -i file.flac -vn -f mp3 -ab 320k - | vlc - nothing is truncated [08:53] <road|runner> my flac files contain 2 streams, video (cover art) and the flac compressed audio stream [09:00] <road|runner> i have to say sockso invokes transcoding script passing as the first parameter path and reads transcoded streams from stdout [10:45] <kode54> weird [10:45] <kode54> I am trying to use ffmpeg to convert from H.264 to WebM [10:45] <kode54> and the source video has a tbc of 59.94, but appears to be entirely progressive [10:45] <kode54> yet when I convert, the result looks like it was fed through a nasty field blending deinterlacer [11:16] <brontosaurusrex_> kode54, vp8? [11:16] <kode54> yes [11:17] <Mavrik> kode54, that's usually what happens when your bitrate/quality is too low [11:18] <kode54> I tried using -qmin 0 -qmax 25 -crf 5 -v:b [11:18] <kode54> I assume it's bad to mix crf with v:b [11:18] <kode54> v:b 1700k [11:18] <Mavrik> it's pointless. [11:18] <kode54> ah [11:18] <Mavrik> and it probably confuses the heck out of the encoder :P [11:18] <Mavrik> there's also a "speed" setting [11:19] <kode54> what are the speed settings available? [11:19] <brontosaurusrex_> last time i tryed vp8 it didn't have crf [11:20] <brontosaurusrex_> so that must be new ... [11:23] <kode54> wow [11:23] <kode54> comes out bad even when I use -minrate 1700k -maxrate 1700k [11:23] <Mavrik> afaik minrate and maxrate don't do anything with vp8 [11:23] <kode54> oh [11:24] <Mavrik> or at least not with any good effect [11:24] <Mavrik> even though this tells that they do: http://people.xiph.org/~j/ffmpeg.html [11:24] <Mavrik> this gave me pretty good resuts with older vpx/ffmpeg : https://www.virag.si/2012/01/webm-web-video-encoding-tutorial-with-ffmpeg-0… [11:24] <kode54> b:v is what I meant above, but yeah [11:31] <kode54> no matter what settings I use, it ends up producing a video which is ~504kbps, including the 128kbps vorbis audio [11:31] <kode54> do I have to specify the video codec manually? [11:32] <kode54> it already defaults to libvpx when I specify .webm for output [11:40] <brontosaurusrex> kode54, i can post my horrible ffmpeg|vp8 pipe commands if you wish [11:40] <brontosaurusrex> but they are dated [11:40] <kode54> not sure if I can build vpxenc anyway [11:41] <kode54> http://mobile.foobar2000.com/kickstarter/kickstarter-foobar1.mp4 maybe it's the video, lol [11:41] <kode54> I'm trying to prepare something for spoon [11:41] <kode54> in case he doesn't want to encode his own webm format [11:41] <kode54> he used some generous bitrate for the source video [11:42] <brontosaurusrex> you guys are from hydrogenaudio? [11:42] <kode54> I am [11:42] <kode54> and somehow got hooked into working on this mobile thing [11:43] <kode54> no idea what use I'll be [11:43] <brontosaurusrex> yeah, i read about it [11:44] <brontosaurusrex> seems confusing to me, but i'am more of a mobile hater, so does not matter really [11:46] <brontosaurusrex> so do you people need a video guy? I could do that video soooo much better [11:47] <brontosaurusrex> catch: I want shares [11:49] <Mavrik> kode54, yeah, that looks like a type of video where encoder will refuse to increase bitrate [11:49] <Mavrik> but the fuzzyness is interesting [11:49] <Mavrik> do you have the latest libvpx and ffmpeg? [11:56] <c_14> kode54: I just tried encoding the video you posted to webm with vp8 and I got 1012kb/s total and the video looks fine. Like Mavrik said, I'd check to see you are using the newest versions of ffmpeg and libvpx. [12:00] <wickwire> Hi everyone, I was asked to investigate a solution and after much googling and since I don't know that much about it, I thought I'd ask [12:01] <wickwire> I'm working on an RTP/RTCP server-client implementation [12:01] <wickwire> which is working [12:01] <wickwire> but now, I've been asked to implement a sort of "burst" mode on it [12:01] <wickwire> meaning, upon request, the sender party should send the video over RTP, [12:02] <wickwire> faster than playback time [12:02] <wickwire> so that in theory, the client would have all the video as fast as possible [12:03] <wickwire> in case the server (sender) should fall [12:03] <wickwire> is this kind of "burst", "lazy loading" scenario possible with RTP...? [12:04] <wickwire> I have found that if I activate buffers and caching on the client, I'm able to store the feed and if the server falls, the video still plays [12:04] <wickwire> but that implies waiting to start streaming, to build the cache - and it won't do me any good in this case, as I also need the client to start playing the content as soon as possible [12:05] <wickwire> does anyone have any suggestions or clarifications on this, if possible, where should I start...? [12:05] <wickwire> thanks in advance [12:06] <Mavrik> hmm, I haven't seen anything like that done with RTP [12:06] <Mavrik> but that's basically how RTMP works [12:07] <wickwire> RTMP? ok I'll have a look at it [12:07] <wickwire> thanks [12:09] <wickwire> RTMP seems to be proprietary [12:09] <wickwire> does ffmpeg handle it properly...? [12:10] <DrewM> "You can add -movflags +faststart as an output option if your videos are going to be viewed in a browser. This will move some information to the beginning of your file and allow the video to begin playing before it is completely downloaded by the viewer. It is not required if you are going to use a video service such as YouTube." <-the FFMPEG wiki article on X.264 encoding. [12:10] <road|runner> hi, i uses sockso streaming server and would like transcode on the fly flac to mp3. to do this i uses ffmpeg -i file.flac -vn -f mp3 -ab 320k -. in most cases this works well but some jobs are truncated. no idea why. when using same construct in windows cmd and pipe the output diretcly to a player ffmpeg -i file.flac -vn -f mp3 -ab 320k - | vlc - nothing is truncated [12:11] <DrewM> Have oyu tried playing the truncated file in multiple players? [12:12] <Mavrik> wickwire, it worked fine for our tests [12:12] <DrewM> A lot of them misreport the length of veriable bitrate audio [12:12] <Mavrik> wickwire, but it's possible RTP/RTSP could have that kind of download control [12:12] <Mavrik> I'm a little rusty on those protocols, I've tried to avoid them as much as possible [12:14] <wickwire> ok Mavrik, DrewM, I'll keep looking, thank you for the help [12:15] <DrewM> It annoys me that everybody encapsulates those protocols in flash. I want the link so i can put it in a media player so I can put it on the right screen. [12:16] <wickwire> DrewM I just read the beginning of http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol [12:17] <wickwire> I'll have a look at what you've described, thanks again [12:18] <road|runner> DrewM: in vlc only... but my flacs contain cover art and id3 tags, could this be an issue? [12:19] <road|runner> stored cover art is 500x500 [12:20] <DrewM> You're right. RTMP is Adobe. But Big Media (Viacom, etc) like it so it tends to be what gets used. [12:21] <DrewM> road|runner: It could. [12:21] <road|runner> is there a way to filter out id3 tags before encoding? [12:22] <DrewM> Er not ID3 tags. And I wouldn't think that cover art would either but it's a relatively new thing and I've learned to never say never. [12:23] <jonascj> I've setup an ffmpeg->ffserver mjpeg stream. It works fine in VLC player (2-3 seconds delay) but I cannot use it in a browser. With the risk of someone in our print lab flashing the camera here goes - right now it just displays a computer screen because the camera sits on a desk: http://thecheat.colding.com:8090/webcam.mjpeg [12:23] <jonascj> any ideas why that url does not work in a browser? [12:24] <brontosaurusrex> jonascj, since browser has no idea on how to decode .mjpeg? [12:25] <jonascj> brontosaurusrex: on wikipedia and tutorials you can read that mjpeg enjoys native support in many browsers... but I haven't found it so (just like you say) [12:25] <brontosaurusrex> works fine here with mpv player [12:26] <jonascj> brontosaurusrex: yeah, it works for me with vlc player. [12:26] <jonascj> Now I would just like to view it in a browser but that seems to be a hard task. [12:26] <brontosaurusrex> use something else, like light h.264 [12:26] <DrewM> It opened but it downloaded continuously. You could probaby make an HTML that includes it as part of the page. [12:27] <brontosaurusrex> or that [12:27] <brontosaurusrex> but what component would actually play mjpeg? [12:27] <DrewM> No idea. [12:27] <DrewM> But if it's there it should know what to do with it. [12:28] <jonascj> people in #html5 say that "properly encoded mjpeg should work in <img src="host.com/webcam.mjpeg"> [12:28] <DrewM> I don't get why youtube doesn't have video in firefox without flash. [12:28] <jonascj> they are not necessarily video wizads (neither am I) [12:29] <jonascj> do you guys know about webm? That is suppose to work with html5's video tag [12:30] <brontosaurusrex> jonascj, you still won't cover every browser and vp8 is pain in the ass to use, seriously i'd just use x264 [12:30] <brontosaurusrex> jonascj, then you can make flash/html5 thingy to display the video [12:31] <jonascj> brontosaurusrex: okay, so you'd say x264 (which is mpeg4?) and then get some player (flash, html5, javascript, whatever) to play it? [12:32] <brontosaurusrex> jonascj, yes, the idea would be to use html5 for browser that support h.264 decoding natively and flash for the rest [12:32] <brontosaurusrex> browsers [12:33] <jonascj> okay, thanks [12:34] <jonascj> on another node - do you know what I would have to read up on if I wanted ffmpeg to just push single jpegs to a custom server / distributor application I would write? [12:34] <jonascj> *note [12:34] <DrewM> FF got native X264 decoding just a few months ago. [12:34] <jonascj> Is it called streaming if you just transmit one whole jpeg after another, and on the receiving end push them along to some javascript which will then render them? [12:35] <DrewM> So I'm not sure what doesn't support it by now... TOR users? [12:35] <jonascj> DrewM: but does that work with live streaming also or just treaming of static files? [12:38] <DrewM> It seems most are still using flash right now but i'm not sure what the future will hold. I don't even know if HTML5 has stuff for streaming in it or not. I'd think that it does but haven't looked yet. [12:39] <DrewM> Regardless there's a lot of cases where people use flash applets where they don't need to. There's a handy greasemonkey script I've been using lately called Linternamagica that tries to grab the MP4/webm resource out of the flash code and put it in the browser's standard videoplayer object. I love it muchly. [12:40] <jonascj> I think I'll give webm a chance. It seems to work with the major browsers (latest versions) and the <video> element [12:41] <jonascj> It might be some work compiling ffmpeg to have the right libraries and afterwards some work finding the right ffserver config for it. [12:42] <DrewM> Webm only accepts ogg vorbis so your audio will most likely need to be transcoded. Though you were probably going to transcode to aAC for MP4 anyway. [12:43] <DrewM> The x264 wiki has stuff on webm transcoding. I dont' remember how much of it talks about streaming though. [12:43] <DrewM> Er, ffmpeg wiki I mean [12:43] <DrewM> durp [12:44] <azk> I recently set that up with ffserver [12:44] <azk> Works fine with chromium/webkit [12:44] <azk> No sound on firefox atm [12:44] <DrewM> Webm should have FLAC as an option IMO. Even if nobody uses it. I suppose no one's calling webm an HD codec so I suppose that's never gonna happen. [12:44] <JEEB> webm is just a subset of matroska [12:45] <c_14> webm also has opus if you -strict -2 [12:45] <c_14> But opus support isn't everywhere yet, sadly. [12:45] <JEEB> not sure if the opus output that ffmpeg does is correct :s never checked if they fixed it [12:46] <DrewM> That would make it an amazing option for a VOIP program. [12:46] <JEEB> anyways, too bad libvpx is bad :P [12:46] <JEEB> with both vp8 and vp9 [12:47] <DrewM> See i like Metroska a lot because you can mux anythign to it and it doesn't care. Whereas Webm has 1 codec for video and 1... apparently 2 for audio. So it's like Metroska accept with all the useful bits taken out? [12:47] <JEEB> it's more or less got two video and two audio formats atm [12:47] <JEEB> vp8 and vp9 for video [12:47] <JEEB> vorbis and opus for audio [12:47] <DrewM> I forget about VP9. [12:48] <DrewM> Still. [12:48] <c_14> webm was built around free formats, precisely so you can implement it in any browser without having to pay royalties [12:49] <DrewM> Which is really cool if you make browsers! [12:50] <c_14> It's really cool if you're making anything where you want to use video/audio without having to pay royalties. [12:50] <JEEB> vp9 kind of had a chance since as a format it is better than AVC, but too bad google doesn't seem to want anyone to use it :P [12:50] <JEEB> the encoder is slow as molasses and they're not interested in multithreading it either [12:51] <JEEB> also the on2 style of format development is still active as it was probably with vp8 when it was within on2, everything's behind closed doors and there's no specification [12:51] <JEEB> the implementation _is_ the specification [12:52] <DrewM> Right. *I* understand that webm is better legally. But I don't need to, I don't make content. [12:52] <JEEB> uhh [12:53] <JEEB> just call the actual a/v formats instead of "webm" [12:53] <JEEB> it's a container for eff's sake (subset of matroska) [12:55] <DrewM> IMO, A container format that can only contain 2 possible codecs for A/V is not very useful. Were either of these codecs a defacto video standard this would be less of an issue, but I dont' see VP8 many places outside youtube. [12:56] <JEEB> It's used in some places, generally around freetards. It helps that AVC delivery for free on the internets is not needing of a license. [12:56] <DrewM> And if people aren't using it they don't know about it and thus continue not using it. [12:57] <JEEB> basically, libvpx with vp8 encoding is slower and gives worse results on the same average rate than libx264, thus not many actually want to use it :P [12:57] <JEEB> VP9 would be actually a useful way of getting people to use such a format... but google is totally missing the chance with the implementation [12:57] <JEEB> because the goddamn encoder is _slow_ [12:58] <JEEB> like, when your encoder is in a similar ballpark as the HEVC reference encoder, you're doing it wrong [12:58] <DrewM> Yeah, sorry--I really mean "apart from web page embeds" but if YT didn't roll it out I really don't think it woudl be used nearly as much as it is. [12:58] <JEEB> (I know that libvpx is generally speaking a reference implementation as well, but it's actually also meant for end-users :) [12:59] <JEEB> also 4chan recently started letting people uploading vp8 webm clips as an alternative for gifs [12:59] <JEEB> which kind of pushed interest, but I really dunno... :s [12:59] <DrewM> I haven't kept up with VP9. Is there just the one encoder for it? [13:00] <JEEB> yes [13:00] <JEEB> pretty much just like with VP8 [13:00] <DrewM> Is it opensourced like 8? [13:00] <JEEB> yes [13:00] <DrewM> So if Google's dragging its feet couldn't someone else fork it? [13:00] <JEEB> well [13:00] <JEEB> the problem is that there's the HEVC format [13:00] <JEEB> which is an actual standard [13:01] <JEEB> and the OSS implementations around it are already ending up better :P [13:01] <JEEB> I mean, ~10x slower than x264 is already not bad, considering the specification was finished in 2013 [13:01] <DrewM> So it's MP3 round two. That's alright with me [13:01] <JEEB> (same as with VP9, which was in June or so of 2013) [13:02] <JEEB> so basically the lack of interest for VP9 comes from the fact that it isn't currently already somewhat usable, and if people wanted to contribute to something they usually pick the thing that's similar and furthest away [13:02] <JEEB> from the starting point [13:02] <JEEB> and given that VP9 is only cared about by Google and Google alone... [13:03] <DrewM> Right, I see. And 2 years from now everyone's already got their content stable and won't want to transcode. [13:03] <JEEB> as I already noted, if Google had tried to push the encoder to at least be in a similar ballpark as the least bad HEVC encoders [13:03] <JEEB> they would have had an actual chance [13:04] <JEEB> since firefox and chrome already have support for decoding [13:04] <JEEB> and HEVC is not yet deployed anywhere in the web except for divx's crappy plugin [13:04] <JEEB> makes me sad :P would have been a switch, and actual progress from AVC [13:04] <DrewM> I'm still puzzling out the politics of the move to open source those formats. What do they get out of having people use their video format when they already have the world's most popular video sharing service? [13:05] <DrewM> Forgive me if I'm asking dumb questions that everyone knows the answer to already [13:05] <jonascj> video is hard [13:06] <JEEB> I don't think anyone here can say for sure what Google was/is trying with the acquisition of On2, but I'm pretty sure it has at least partially to do with people having to use their stuff, instead of other people's stuff [13:07] <ubitux> i'd they don't need people to be able encode in vp9; they just needed vp9 to lower the bw cost from yt, and they need the codec to be opensource so the decoder is available everywhere [13:07] <ubitux> i guess that's all there is :p [13:07] <ubitux> i'd *say* [13:08] <DrewM> Right but they already have market dominance. They can switch youtube over to webm and kill X264 and watch the browsers scramble to suddenly implement VP9 because they can't watch their favorit musical cat videos. Since so many people are on youtube it accomplishes a similar thing with much less of a concession. [13:09] <DrewM> Er, I mean kill their use of it on youtube, not everywhere, obviously [13:09] <JEEB> x264 is an implementation, not a format [13:09] <JEEB> just FYI [13:09] <JEEB> the format can either be called AVC or H.264 [13:10] <JEEB> (the ISO and ITU-T names) [13:11] <DrewM> Sorry. I do sort of know that but use them interchangably in my own head anyway. [13:13] <DrewM> I also know there is much more to the scene than YT, but no browser is going to let the users just not have access to it. Or everyone will just switch to Chrome and abandon them. [13:21] <jonascj> For really slow webcam feeds (1-5fps) could one capture single jpeg and push to distribution which would serve them to some "viewing / rendering application" (javascript which just renders each frame as it arrives)? [14:15] <anshul__> how to check vlc is compiled with ffmpeg [14:15] <anshul__> I want to apply break point on any function of vlc [14:25] <superc2_> hi. still trying to get a basic setup running with ffmpeg... just reinstalled everything and took the sample ffserver.conf file from the sources... however I'm still not able to see anything. [14:26] <superc2_> so basically I'm trying to stream my webcam with vlc from a windows machine to the ffserver and then from there back to a windows media player [14:27] <superc2_> for vlc... is rtsp streaming the right option? [14:38] <superc2_> anyone there? [14:38] <superc2_> if the connection status is in State "WAIT_FEED" the transmission from vlc to the server does not work, right? [15:34] <Mavrik> hmm [15:34] <Mavrik> do we have a barrel distortion filter in ffmpeg yet [16:20] <Voicu> hello [16:21] <Voicu> I'm trying to decode a (maybe) broken aac stream [16:21] <Voicu> and I get errors of the form "channel element x.x is not allocated" [16:21] <Voicu> what does that mean? what is actually missing? [20:19] <bakers> Does ffmpeg default to using vp8 or vp9 for .webm titled files? [20:20] <c_14> vp8 afaik [20:20] <bakers> how do I specify vp9 vs vp8 on the CLI? [20:20] <c_14> -c:v vp9 [20:20] <bakers> c_14: That's too easy :) [20:20] <bakers> ok [20:21] <c_14> You might want to read: https://trac.ffmpeg.org/wiki/vpxEncodingGuide [20:21] <c_14> It doesn't have everything, but it's useful. [20:23] <c_14> You can also look at ffmpeg -h muxer=webm and ffmpeg -h encoder=vp9 [20:27] <bakers> is there a long hand form of -c:v ? [20:27] <bakers> --codec:video ? [20:28] <c_14> There's -codec:v [20:29] <bakers> "-codec:video" appears to work [20:29] <bakers> Thanks [20:30] <c_14> np [21:00] <haptiK> hi c_14 [21:01] <c_14> hi [21:16] <pzich> so...I'm trying to H.264 encode a video that's 5760x1200@30, and I'm getting garbled results. The internet is suggesting that this is just way too big for H.264 to handle, am I just SOL? [21:45] <JEEB> pzich, H.264 with libx264 should encode that just fine, as long as you make sure it doesn't go out of address space :P [21:46] <JEEB> regarding decoding, that /should/ be fine too, given that height is even less than 3840x2160 [21:46] <JEEB> which is decoded just fine by recent enough lavc [21:46] <JEEB> basically, I recommend a 64bit build of a recent enough libx264 for the encoding part [21:48] <c_14> Just a note of warning though, I just tried upscaling one of my videos to 7680x4152 for testing purposes and my computer crashed. [21:48] <JEEB> probably a different reason for that :P [21:49] <pzich> I've not had any crashes, but the output video is not looking write, uploading screenshots and command now [21:49] <JEEB> pzich, what have you tested it with? [21:49] <pzich> I'm viewing with Quicktime 7 and VLC. [21:50] <JEEB> ok, QT is known to derp [21:50] <JEEB> what OS are you on? [21:50] <pzich> yeah :/ [21:50] <pzich> OS X [21:50] <JEEB> go grab an mpv build [21:50] <JEEB> and check with it [21:50] <c_14> >ffmpeg invoked oom-killer: [..] [21:50] <JEEB> http://mpv.io/installation/ [21:50] <c_14> Then x died and ... [21:50] <JEEB> c_14, yes -- if you start using a lot of RAM and you don't have it or swap, then suddenly linux starts killing things :) [21:51] <JEEB> pzich, scroll down to the OS X part basically [21:51] <pzich> JEEB: will take a look, thanks [21:52] <JEEB> it's a command line player, but the binaries should be built with new enough stuff [21:53] <JEEB> anyways, in cases like this it's better to provide a sample of the encoded stuff, rather than screenshots. that way you can also have others look how it looks for them in their things :P [21:53] <JEEB> but the command line and the full terminal output would be helpful [21:54] <pzich> yeah, I'm actually thinking this is QT7's fault, and this encode is an intermediate step for another program to interpret, so I'm going to poke at that a bit. [21:54] <pzich> Also, I'd be willing to share, but it's currently still semi-confidential material. [21:54] <JEEB> yeah, you generally can test with similar - even generated content, and see if that looks the same [21:55] <JEEB> and then post that [21:55] <JEEB> just for future reference [21:55] <pzich> yeah, I'm going to try knocking out something at the same size and encoding as the source if I can't get this working in the next ~15m [21:55] <pzich> thanks for the help thus far [21:58] <phelix> for some reason with my video player the audio tends to face in and out and in and out again on some videos.. Is there a type of audio opions I could use when converting a video that might prevent this from happening? [22:01] <pzich> phelix: could you create a paste with the command you ran that you're seeing this issue, and the ffmpeg output for the encode? [22:14] <phelix> ffmpeg -i ./video.mp4 -preset veryfast -vf scale=854x480 -aspect 16:9 -vcodec libx264 ./video.mp4 [22:14] <phelix> i mean ffmpeg -i ./video.mp4 -vf scale=854x480 -aspect 16:9 -vcodec libx264 ./video.mp4 [22:19] <phelix> this is happening on the orignal video and the converted one. It may be my player. But i am wondering if there is another route i can try to encode with on the audio that might help this problem [00:00] --- Tue Apr 29 2014

1 0

ffmpeg-devel.log.20140427
by burek 28 Apr '14

28 Apr '14

[03:23] <michaelni> ubitux, coverity found an issue in vf_curves.c (1206650) [03:36] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:6956b048d819: avfilter/vf_drawtext: fix resource leaks [05:45] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:09b16619d33d: ffmpeg_filter: fix pointer to local outside scope [05:45] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:bc3234062d08: avcodec/truemotion2: replace impossible condition by av_assert2 [05:45] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:b4329605289e: avcodec/mjpegdec: Fix undefined shift [05:58] <michaelni> ubitux, also CID1194399 (f_ebur128.c) [06:01] <jamrial> the ebur128 test has been failing on msvc < 2013 for months now, btw [11:32] <ubitux> michaelni: ok, will look at it in a moment [11:53] <cone-415> ffmpeg.git 03Clément BSsch 07master:b2cfd1fde7a2: avfilter/curves: fix resource leaks. [12:08] <ubitux> michaelni: there is no risk of reading more than one channel in swr with packed sample fmt, right? [12:08] <ubitux> (i'm asking because i have a double *buf and i'm sending &buf to swr_convert) [13:07] <michaelni> ubitux, the docs say " @param in input buffers, only the first one need to be set in case of packed audio" so it would be a bug if it read more [13:19] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:e20ebe491c17: avcodec/shorten: check bitshift [13:55] <cone-415> ffmpeg.git 03Carl Eugen Hoyos 07master:ade5851be085: Try mov tags if the fourcc in V_MS/VFW mkv files cannot be found in bmp tags. [13:55] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:7e7b668ef50c: Merge remote-tracking branch 'cehoyos/master' [14:36] <cone-415> ffmpeg.git 03goodthanks 07master:c9cfd4583891: avformat/mpegtsenc: Allow DTS audio copy to TS streams [14:45] <cone-415> ffmpeg.git 03Peter Ross 07master:bdab0c2d7643: avformat/mlvdec: process ff_get_wav_header return value [14:45] <cone-415> ffmpeg.git 03Peter Ross 07master:9abf08f79fb3: avformat/mlvdec: print unsigned chunk size [15:01] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:e9ad121ba532: Fix skiping typos [15:04] <wm4> "skiping" is a typo in itself [15:05] <wm4> oh I see [15:05] <wm4> it was a trap! [15:09] <cone-415> ffmpeg.git 03Carl Eugen Hoyos 07master:4abbea0243ec: lavf/mpeg.h: Remove an unused definition. [15:09] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:e2a5557cbb7f: Merge remote-tracking branch 'cehoyos/master' [15:11] <wm4> so... we don't have a float pixel format? [15:12] <nevcairiel> not that i'm aware [15:12] <nevcairiel> do you need one? [15:12] <wm4> there was someone complaining about getting banding when decoding EXR images [15:12] <wm4> because the decoder converts floats to ints [15:12] <nevcairiel> i've never seen float image data outside of the GPU really [15:13] <nevcairiel> into what kind of integer? [15:13] <nevcairiel> with 16-bit you should probably get enough precision to avoid any kind of banding [15:13] <wm4> yes, 16 bit [15:14] <nevcairiel> maybe whatever he uses to view the image just doesn't dither, and rounds to 8-bit for display [15:14] <nevcairiel> float isn't going to fix that [15:14] <wm4> that user posted a patch that allows applying gamma to the image [15:14] <nevcairiel> considering displays are typically 8 bit or tops 10 bit, 16 bit image data is plenty [15:14] <wm4> so he's probably not totally clueless about this [15:17] <nevcairiel> i dunno, 16-bit integer should be plenty to do gamma processing after [15:19] <wm4> well, the floats are half-floats too [15:19] <wm4> so I think this is more a problem that integers are unsuitable for high dynamic range stuff [15:19] <nevcairiel> then 16-bit integer even has more precision [15:20] <nevcairiel> I suppose if all that precision is in rather dark areas, it might be a bit problematic [15:24] <nevcairiel> if someone wants to introduce floating point RGB... just don't use half-FP, its stupid to handle in C code, expand to full 32-bit FP ("float") :d [15:28] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:466988ab7536: Fix dont and doesnt typos [15:28] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:a5e20d9f4d5d: Fix teh typos [15:28] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:9341e9497b11: Fix overriden typos [15:28] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:3a5ca79b0c2c: fix bistream typos [15:28] <nevcairiel> whats with typo-sunday [15:30] <wm4> - The bistream buffers no longer need to be explicitly freed. [15:30] <wm4> + The bitsream buffers no longer need to be explicitly freed. [15:30] <wm4> shouldn't it be bitstream [15:30] <nevcairiel> hehe [15:30] <nevcairiel> it should [15:32] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:ef312b8f0f47: Fix bistream typos [15:33] <wm4> looks ok now [15:33] <nevcairiel> there is a typo in the commit message, should be "Fix bitsream typos" [15:33] <nevcairiel> :D [15:33] <michaelni> darn ;) [16:37] <cone-415> ffmpeg.git 03Peter Ross 07master:8bd6837e5105: avformat/mlvdec: remove unused MlvContext.buffer [16:37] <cone-415> ffmpeg.git 03Peter Ross 07master:b3c0d010c3c7: avformat/mlvdec: close any additional .Mxx files [17:01] <j-b> [tiff @ 0x7fbef8004a00] Color mode 6 is not supported 0B f=0/0 [17:01] <j-b> Does this ring a bell? [17:02] <j-b> ah, yeah [17:02] <j-b> http://trac.ffmpeg.org/ticket/416 [17:10] <wm4> j-b: do people use vlc as image viewer? [17:10] <j-b> No [17:11] <j-b> but seriously, creating .tiff images that you can't even open? Good job... [17:11] <wm4> hah [17:11] <wm4> better than the other way around [17:11] <j-b> No. [17:11] <wm4> (generating files only ffmpeg can handle) [17:38] <nevcairiel> encoders and decoders are typically entirely separate code =p [18:10] <ubitux> michaelni: didn't you mean softfloat for exr? [18:14] <michaelni> softfloat would probably be rather slow [21:09] <cone-415> ffmpeg.git 03Lukasz Marek 07master:4930e529bfd3: lavd/fbdev_enc: fix not closed handles [21:09] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:1ca21e1b767a: avcodec/tiff: parse subsample factors [21:09] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:d03defa778bd: avcodec/tiff: Support yuv 420 and 444 [21:10] <michaelni> j-b, yuv420 tiff ixed [21:10] <michaelni> Fixed [22:16] <j-b> michaelni: lol :) [22:24] <Compn> did i miss a funny ? [23:21] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:1fc28cf1644e: avcodec/g729postfilter: avoid potential negative shift [00:00] --- Mon Apr 28 2014

1 0

ffmpeg.log.20140427
by burek 28 Apr '14

28 Apr '14

[00:23] <ac_slater> hey guys. I'm just really digging into different encoders, etc. It seems MPEG2-TS is special thing. Does it make sense to wrap MJPEG into a MPEG2-TS container? I need MPEG2-TS for MISB metadata. Any help would be awesome. Thanks! [02:39] <fyp> is this the help channel [02:40] <fyp> I compile using this guide normally : https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [02:40] <fyp> works perfectly until now, since I upgraded to mint 16 [02:40] <fyp> had no choice with the ssl stuff [02:40] <fyp> can I paste the compilation error in pastebin? [02:40] <fyp> have some of you guys tell me whats wrong [02:40] <fyp> pl [02:40] <fyp> pls [02:41] <fyp> thing is, weirdly, it worked before, kinda, i couldn't make sudo make checkinstall, so ffmpeg works as commandline but isn't integrated to the packages [02:42] <fyp> now it wont even compile right...uh [02:43] <klaxa> yes pastebin your error and preferably your config.log [02:44] <fyp> where would that config.log be [02:44] <fyp> i use linux since 2 years, there's still things i'm not 100% un-noobed with [02:44] <fyp> im wondering if i should just start over with the other packages to install and integrate in ffmpeg first [02:45] <fyp> cos i could compile it [02:45] <fyp> the real issue was not being able to make checkinstall it [02:45] <fyp> so no .deb [02:45] <fyp> no installation into the system [02:45] <fyp> just a command line.. [02:45] <klaxa> the config.log will be in the same directory you ran ./configure in [02:46] <fyp> let me reinstall all those things to compile ffmpeg with first klaxa, then i'll do this [02:46] <klaxa> alright [02:47] <fyp> shouldnt be long [02:47] <fyp> only one takes a while but with make -j its a breeze [03:08] <fyp> need to reboot, but i'll be back in 2 mins klaxa...the ffmpeg adjuncts are compiling [03:43] <azk> Is there any way to have ffserver use the original file's size instead of specifying a fixed VideoSize? [06:08] <fyp> ugh [06:08] <fyp> the guy who was gonna help me is gone [06:09] <fyp> i used this guide before in the past no problem [06:09] <fyp> https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [06:10] <fyp> to compile ffmpeg with a lot of useful options in [06:10] <fyp> but this time, i can't get ffmpeg to install as a package, only can use it as a command line [06:10] <fyp> because libvpx 1.3.0 won't install correctly [06:10] <fyp> i'll put whats up on pastebin and waste [06:10] <fyp> wait [06:12] <fyp> http://pastebin.com/c20FHVdY [06:12] <fyp> i used checkinstall like on most everything instead of make and make install and i actually got further [06:12] <fyp> installation successfull...debian package installation failed [06:13] <fyp> so i'm not sure if it's in the ffmpeg temp files [06:13] <fyp> and also, i want to make a deb out of compiling ffmpeg like I used to [06:13] <fyp> i have a custom made one for my computer but....i changed video card(s) then [06:13] <fyp> went from a gt 230 geforce to 3 7850HD radeons in crossfire [06:15] <fyp> gonna try the final ffmpeg step and see if anyone can help, would appreciate it [06:24] <fyp> i actually donated to this project twice, so, yeah cant prove it, but all conceitedness aside, if this ffmpeg "successfully installs" meaning only a command line works and no deb package gets installed into the system im gonna fuckin go mad [06:44] <fyp> yeah thats great, can't even pull man ffmpeg [06:44] <fyp> tells me about the dummmy man 7 undocumented [07:04] <The_Ball> I'm trying to find out if a security camera puts additional information (like motion detection triggers) in the transport stream. It's a RTSP transport which ffplay reports as containing two streams: Stream #0:0, 28, 1/90000: Video: h264 (Baseline), yuv420p(tv), 2048x1536 [SAR 1:1 DAR 4:3], 1/180000, 15.17 tbr, 90k tbn, 180k tbc and Stream #0:1, 1, 1/90000: Data: none, 0/1. Is there a way I can dump anything that is being s [07:04] <The_Ball> ent in the data stream? [07:06] <The_Ball> Or could there be KLV fields hidden in the h264 stream perhaps. Would -loglevel debug show any embedded KLVs? [09:32] <jonascj> So I am still playing around with live streaming a webcam for viewing in a web browser. The solution I like best so far is http://phoboslab.org/log/2013/09/html5-live-video-streaming-via-websockets but it I cannot get it to work with low framerates due to some mpeg1/2 or codec limitation. [09:33] <jonascj> It is an javascript mpeg1/2 decoder which receives the stream from ffmpeg via http, extracts the frames and insert them into an html5 canvas element. [09:36] <jonascj> My question is could this be done without a conventional video stream (mpeg for example)? Could I just setup ffmpeg to capture single jpeg images and deliver them to a server application which will then process them? 1-10 FPS sounds like something which could be done with such a solution [10:09] <SpecialEd> Hey guys, recently on ffmpeg I've been getting a lot of "AVC: nal size #######" and "missing picture in access unit with size 42" errors echo'd to my Ubuntu terminal shell when transcoding flash video to x264 mp4. [10:09] <SpecialEd> The videos still play fine, but its kinda annoying how its basically spamming my terminal session, anyone else encounter this and/or know how I could quiet this down? [11:35] <stylus_Jack> Hi, how can I get identical or near-identical results for conversions of the same file with the same output settings across different versions/builds of ffmpeg? [11:44] <stylus_Jack> Output summary: http://pastebin.com/raw.php?i=64xyHB2g [13:44] <kcynice> hello all, is there a offline api document for downloading? [13:46] <klaxa> you can build it from the source-tree [13:47] <kcynice> how to do that? [13:48] <kcynice> i can't find a doxygen shell script to do it [13:49] <kcynice> any hints? [13:50] <kcynice> from configure, i can only find disable-doc, but i have not disable it [15:52] <azk> Hi, can anyone explain to me the reason ffserver streams default to 160x128 instead of determining the source file size? [17:48] <Jaska_> [Parsed_overlay_3 @ 0x235d2e0] [framesync @ 0x235d3c8] Buffer queue overflow, dropping. [17:48] <Jaska_> trying to create 2x2 grid of 2 vids and 2 images.. [17:49] <Jaska_> 2 identical videos at constant framerate 30 [17:50] <Jaska_> so yeah, how do i avoid dropping frames? [17:51] <Jaska_> 2 rtmp streams -> 1 rtmp stream 2x2 grid [17:51] <Jaska_> + the jpg's [17:58] <Jaska_> nvm it will never work anyway [18:18] <Jaska_> ffmpeg just doesnt like rtmp streams encoded on fly? [18:35] <Jaska_> ah nevermind thanks -re did the trick [19:06] <t4nk595> does anyone have experience streaming MP4 input to HLS with ffserver? [19:18] <randomguy123> i'm trying to stream theora/ogg from ffserver that's being fed by ffmpeg. It doesn't work. What do I need to do? I use mp4 file as an input to ffmpeg, but I get a error right away: av_interleaved_write_frame(): Unknown error [19:18] <randomguy123> for ffserver config i use: https://trac.ffmpeg.org/wiki/Streaming%20media%20with%20ffserver#StreamingT… [19:19] <randomguy123> for ffmpeg i use this cmd: ffmpeg -i VID.mp4 http://localhost:8090/feed1.ffm [19:24] <__raven_> hi [19:26] <__raven_> trying to merge two video/audio-files gives me that error: Application provided invalid, non monotonically increasing dts to muxer in stream 0: 184230 >= 169830 whats that and how to solve? [19:36] <mleise> I get an error message for some H.264 steam copy with -fflags +genpts (maybe unrelated): [19:36] <mleise> [NULL @ 0x64b2a0] non-existing SPS 32 referenced in buffering period [19:37] <mleise> What is a SPS? [19:37] <jonascj> Hi all. The single jpeg option for ffserver, what is that? [19:37] <jonascj> https://www.ffmpeg.org/ffserver.html [19:58] <c_14> mleise: SPS or the Sequence Parameter Set is h264 metainformation that decoders use to decode video files. [19:58] <c_14> Is that an error (ffmpeg stops running) or a warning (ffmpeg keeps running) [19:59] <mleise> c_14: it is both... a red ERROR, but it keeps running [19:59] <mleise> would that mean I could have lost information? [20:00] <mleise> The source was from PowerDirector 12. Then I ran mkvmerge on it to add chapters. [20:01] <mleise> Then I noticed severe slowdowns of some parts (I assume GOPs) and ran mkvextract to get back a H.264 elementary stream [20:01] <c_14> It means that the source file is (at least partially) corrupted (ore just encoded incorrectly). Since you are using stream copy, the resulting stream should be identical to how an h264 decoder sees the first stream. (which may or may not be broken) [20:02] <c_14> It should be fine though as long as the sps information is stored somewhere else within the file as well. [20:02] <c_14> You'll probably just get that error every time you try decoding the file. [20:02] <mleise> Then I ran avcon...err...let's say ffmpeg -f h264 -r 50 -fflags +genpts -i h264file -codec copy out.mp4 [20:03] <c_14> As long as the error isn't fatal and you can play the output, you should be fine. [20:03] <mleise> hmm, so this error was most likely already in the original .m2ts? [20:03] <mleise> ok [20:06] <mleise> c_14: could that be related to the warning in mkvmerge that CTTS is unavailable? Is that part of the SPS or vice versa? [20:07] <muken> none [20:13] <c_14> It's similar, but I don't think it's directly related. [20:14] <c_14> As long as the output looks fine, I wouldn't worry about it. [21:00] <ScottSteiner_> I'm trying to burn subtitles into a video. Is it possible to search ahead to a keyframe and then burn the subtitles in, while keeping the same timestamps? "ffmpeg -ss 00:10:00 -vf 'ass=subs.ass' input.mkv -to 00:00:05 output.mkv" throws an error and putting the filter before the output uses the wrong timestamps [22:14] <Lokie> hello, i followed this guide: https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide to install ffmpeg. I searched a bit but didn't find an answer. When creating a webm is it possible to add subtitles? [22:21] <sacarasc> What kind of subtitles? Soft, hard, if soft, what type? [22:22] <Lokie> on the output should be hardsubs. the input .ass or .srt [22:22] <sacarasc> Yeah, you should be able to do that, just a sec and I'll bring up a guide. [22:22] <c_14> https://trac.ffmpeg.org/wiki/How%20to%20burn%20subtitles%20into%20the%20vid… [22:22] <sacarasc> c_14 wins. :D [22:23] <c_14> hihi [22:23] <Lokie> thx [22:23] <Lokie> sadly ffmpeg failed to compile properly [22:23] <Lokie> i will try a static release for the time being [22:31] <Lokie> is there a reason i should not use the static builds? [22:34] <c_14> You shouldn't use static builds on the 3rd of every month and on even numbered wednesdays. [22:34] Action: Lokie takes notes [22:35] <c_14> As long as the static builds work and have all the features you want, use them. [22:35] <c_14> If you want more/less features you have to build it yourself. [22:35] <Lokie> i see [22:35] <c_14> Also if you need the latest git head, you might need to build it yourself depending on how often the static builds are updated. [22:36] <Lokie> i followed the guide but got hit with: gcc: internal compiler error: Killed (program cc1) [22:36] <Lokie> while building ffmpeg [22:36] <c_14> That's an interesting error... [22:36] <Lokie> and since my skills on linux are well lacking ... [22:38] <c_14> Hmm, according to what I'm reading here, that happens either when gcc has a bug or when it doesn't get enough memory. [22:38] <Lokie> 128M vps [22:38] <Lokie> the 2nd i guess [22:41] <c_14> Could be. If you want to compile it you might want to give it some swap. [22:45] <Lokie> thx for the help btw c_14 [22:45] <Lokie> i never said that :P [22:51] <Lokie> must be it [22:51] <Lokie> another process got killed [22:51] <Lokie> i think both ram and swap wasn't enough [22:51] <Lokie> 128+128 [22:51] <c_14> I'd go with at least 512 [22:52] <mleise> You should try the D programming language. It usually doesn't free memory in the compiler right now :) [22:52] <c_14> Or just use java? [22:52] <mleise> yeah that's a good fit or OpenVZ with all the virtual memory preallocations! [22:53] <mleise> Damn, it could be that my problem is https://trac.bunkus.org/ticket/918 [22:55] <Lokie> sadly can't increase it since it's a rented vps [22:55] <mleise> Probably I should just produce my 4 hour video again and try ffmpeg to create the mkv instead of mkvmerge [22:55] <Lokie> my main box can, but that's why i got some vps try shit there so i avoid bricking my main box XD [22:55] <c_14> Lokie: create a swapfile? [22:56] <mleise> I guess what I don't want is the container to rewrite presentation time stamps. Is that guaranteed for ffmpeg? [22:56] <Lokie> mm [22:56] <Lokie> that could work i guess [22:56] <Lokie> will google [22:56] <Lokie> thx :) [22:56] <c_14> I'm not sure there are any guarantees as far as ffmpeg is concerned, but it hasn't broken anything for me yet. [22:57] <mleise> it only takes a day or two to render the video :D [22:57] <Lokie> i bet, but i prefer to be 100% i can setup something ok before i do it in the main box [22:57] <mleise> and yes it was in four parts until I wanted it as one piece to add chapters and align sub titles [23:18] <SpecialEd> Hey guys, recently on ffmpeg I've been getting a lot of "AVC: nal size #######" and "missing picture in access unit with size 42" errors echo'd to my Ubuntu terminal shell when transcoding flash video to x264 mp4. [23:18] <SpecialEd> The videos still play fine, but its kinda annoying how its basically spamming my terminal session, anyone else encounter this and/or know how I could quiet this down? [00:00] --- Mon Apr 28 2014

1 0

ffmpeg-devel.log.20140426
by burek 27 Apr '14

27 Apr '14

[00:34] <cone-743> ffmpeg.git 03Lukasz Marek 07master:b2682db34c54: lavfi/avfilter: fix typos in doxgens [00:55] <cone-743> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:107f2468c4fc: ffserver: free nacl as needed [00:55] <cone-743> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:1404e2a389fc: ffserver: free AVStream st before wiping context [00:55] <cone-743> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:7228bdeebd28: ffserver: fix missing frees at connection setup [01:40] <cone-743> ffmpeg.git 03Alessandro Ghedini 07master:cdf6eb5a9710: vc1: Do not return an error when skipping b frames [01:40] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:8b2c3d2ae951: Merge commit 'cdf6eb5a9710566be217a3f17d3d94ac4e4d2662' [01:56] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:3ba77ea369a0: avcodec/vc1dec: print debug message if a b frame without reference is skiped [02:26] <cone-743> ffmpeg.git 03Lukasz Marek 07master:b217dc91bfd5: lavfi/avfilter: clarify avfilter_graph_get_filter() doxygen [04:00] <jamrial> BBB: any idea what might be the reason dst in intra_pred 32x32 functions isn't aligned to 32 bytes? [04:00] <BBB> uhm... no not really [04:00] <BBB> is that for chroma or luma? [04:00] <BBB> it sounds like the picture allocation functions themselves don't align to 32bytes [04:01] <BBB> (either the pointer - which is unlikely - or the stride - which is actually quite possibly an issue) [04:05] <BBB> what is pic->line_size[]? [04:05] <jamrial> Not sure, probably both. All the functions i ported to avx2 will complain about alignment when i try to use movdqa with dst+stride [04:08] <jamrial> linesize seems to be 384 [04:10] <BBB> and linesize[1]? [04:12] <jamrial> 192 [04:15] <BBB> and the input pointers allocated are all 32-byte aligned? [04:16] <BBB> (that's pic->data[0-2]) [04:19] <jamrial> That's what i don't know [04:19] <BBB> can you print the pointers in hex? [04:22] <BBB> hm you're right I see the same thing actually [04:23] <BBB> Allocated picture at pointer 0x7fc4c104c610, 0x7fc4c1069610, 0x7fc4c1071010 [04:23] <BBB> Allocated picture at pointer 0x7fc4c1802410, 0x7fc4c181f410, 0x7fc4c1826e10 [04:24] <BBB> so it seems the input pictures aren't well-allocated [04:25] <jamrial> Is that some custom output with av_log you added, or something you get with -loglevel? [04:29] <BBB> custom printfs [04:29] <BBB> this code in utils.c: [04:29] <BBB> // no edge if EDGE EMU or not planar YUV [04:29] <BBB> if ((s->flags & CODEC_FLAG_EMU_EDGE) || !is_planar) [04:29] <BBB> pic->data[i] = pic->buf[i]->data; [04:29] <BBB> else { [04:29] <BBB> pic->data[i] = pic->buf[i]->data + [04:29] <BBB> FFALIGN((pic->linesize[i] * EDGE_WIDTH >> v_shift) + [04:29] <BBB> (pixel_size * EDGE_WIDTH >> h_shift), pool->stride_align[i]); [04:29] <BBB> } [04:29] <BBB> is broken [04:30] <BBB> the input (pic->buf[i]->data) is 32-byte aligned, the output isn't [04:30] <BBB> I guess pool->stirde_align[] is mis-set [04:33] <BBB> ah [04:33] <BBB> /Users/ronaldbultje/Projects/ffmpeg/libavcodec/internal.h:# define STRIDE_ALIGN 16 [04:33] <BBB> that's the basic problem [04:33] <BBB> it should be 32 [04:33] <BBB> I'd precede that with: [04:33] <BBB> #if HAVE_AVX [04:33] <BBB> # define STRIDE_ALIGN 32 [04:34] <BBB> let me see if that fixes anything [04:34] <BBB> yeah all is good then [04:35] <BBB> http://pastebin.com/skCd46Rp [04:35] <BBB> it may break other tests in fate, who knows... [04:35] <BBB> but should be safe [04:36] <jamrial> Cool, thanks [04:37] <BBB> np [04:38] <jamrial> wonder if ubitux's earlier avx2 tests were slow because of this [04:39] <BBB> well he wasn't really using avx2 as full-width, he was doing half-width loop filter (16px per iteration) and then unpacking to full 32bytes for word-operations only [04:40] <BBB> you wouldn't expect to gain much from that, I'll see if I can find some time to add mix4 functions for "proper" avx2 loop filter insertion [04:40] <BBB> that's not exactly easy but it's kind of fun [04:40] <BBB> mc/idct/intrapred should be easier targets [04:41] <jamrial> Ah, i see [04:42] <BBB> vp9 loop filter is kind of ... wierd [04:42] <BBB> weird* [04:42] <jamrial> I so far ported five trivial intra_pred functions. I posted a github link last night [04:42] <jamrial> Great, seems to with with mova now [04:43] <BBB> ash you duplicated pb_1/3 [04:44] <jamrial> I assumed the originals were 16 bytes, so made instead some 32 bytes there [04:46] <BBB> yeah they are, it's probably easier to make the existing ones (I think they're in dsputil_mmx.c) 32-bytes [04:46] <BBB> easier as in more correct [04:46] <jamrial> Sure [04:48] <BBB> code looks good [04:48] <BBB> I guess it's not easy to share code between avx2 and ssse3 right? [04:49] <jamrial> For some i could add a lot of notcpuflag(avx2) checks and such, but it will look pretty ugly [04:50] <BBB> I'd say if the code shared is less than ... say 60% or so, let's not worry [04:50] <jamrial> Now what i need is some kind soul to bench this since i don't have a haswell :P [04:50] <jamrial> Intel's SDE is magic [04:50] <BBB> lol [04:50] <BBB> that sucks [04:51] <BBB> ok I'm gonna sleep [04:51] <BBB> bye [04:51] <jamrial> Night, and thanks again [08:02] <kurosu_> BBB / jamrial: isn't HAVE_AVX for whether the compiler supports AVX (or is it _INLINE)? In any case, the issue with unconditionnally setting it to 32 is only memory consumption? [08:07] <jamrial> HAVE_AVX is always true for x86 unless one disables it during configure. _EXTERNAL is disabled if yasm/nasm isn't available [08:08] <jamrial> there's no check for _INLINE, so it's enabled as long as HAVE_AVX is enabled even if the assembler doesn't support it. but since we don't have any inline avx code it doesn't matter [08:11] <jamrial> and fate passed here with the change BBB mentioned, so yeah it should be safe [13:17] <BBB> kurosu_: yeah that's the intention [13:17] <BBB> kurosu_: clearly if asm/gcc don't do avx, we're not going to have any avx and 32-byte alignment is useless [13:17] <BBB> kurosu_: if gcc/asm do, then we'll contain avx/2 code - now the question is whether we can execute it, that's a runtime thing [13:18] <BBB> kurosu_: I don't mind always-enabling it on x86 honestly [13:18] <BBB> kurosu_: whatever people prefer [14:10] <nevcairiel> memory allocations already use HAVE_AVX to bump the memory alignment to 32 [14:11] <nevcairiel> seems fitting to use the same here [14:15] <kurosu_> I didn't check, but ok - I wasn't doubting, I was just trying to educate myself [14:42] <kierank> great... [14:43] <kierank> usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libavfilter.a(avfiltergraph.o): In function `pick_format': [14:43] <kierank> /media/sf_ffmpeg/libavfilter/avfiltergraph.c:631: undefined reference to `avcodec_find_best_pix_fmt_of_2' [14:43] <kierank> so avfilter now depends on avcodec [14:45] <ubitux> this is here since 2012 afaict [14:46] <kierank> I've never had the problem before [14:46] <ubitux> i wonder why this is not in lavu though [14:47] <kierank> it pretty much breaks anything with --disable-everything [14:47] <ubitux> how do you reproduce? [14:48] <kierank> ./configure --prefix=/usr --enable-gpl --disable-swscale-alpha --disable-everything --disable-avdevice --disable-filters --enable-avresample --enable-decoder=v210 --enable-filter=smptehdbars --enable-filter=smptebars --enable-filter=drawtext --enable-filter=format --enable-libfreetype [14:48] <kierank> and then try and link my application [14:48] <kierank> and it fails [14:49] <kierank> I don't know why it happened all of a sudden [14:50] <ubitux> totally unrelated and you probably don't care but i think you can --enable-filters=smptehdbars,smptebars,drawtext,format [14:55] <kierank> It's not clear what magic incantation I need to get it to link [14:55] <ubitux> well, pkg-config i guess [14:56] <kierank> I'm already using that [14:58] <ubitux> and the pkg-config --libs --static avfilter isn't vomitting enough linker flags? [14:59] <kierank> dunno [14:59] <kierank> there's lots of them yes [14:59] <kierank> gcc -o obecli obecli.o libobe.a -lreadline -L. -pthread -lavformat -lavcodec -lavresample -lswscale -lavfilter -lfreetype -lz -lrt -lavutil -lm -lm -lrt -lpthread -lx264 -ltwolame -lmpegts -lstdc++ -ldl -lzvbi -s [15:00] <kierank> I'm not missing any as far as i can see [15:02] Action: kierank goes back his old ffmpeg to see if it works [15:08] <kierank> gah why does it care all of a sudden [15:09] <kierank> :sigh: [15:10] <kierank> heh put -lavcodec after -lavfilter and it builds [15:10] <kierank> wtf [15:11] <kierank> so the pkg config file is broken basically [16:56] <michaelni> ubitux, avcodec_find_best_pix_fmt_of_2() should be moved to lavu (with appropriate avcodec less name) [17:01] <michaelni> ubitux, do you want to move it or should i look into doing that ? [17:01] <ubitux> not really in the mood for this now sorry [18:50] <michaelni> ubitux, posted patch [19:45] <cone-129> ffmpeg.git 03tue46wsdgxfjrt 07master:262ea965e73e: cmdutils: preserve unchanged log flags when setting AV_LOG_SKIP_REPEATED [19:45] <cone-129> ffmpeg.git 03tue46wsdgxfjrt 07master:669a09fb372f: Add AV_LOG_PRINT_LEVEL flag to include log severity in default log formatting. [20:02] <wm4> anyone have an idea whether this vp9/webm file is broken? http://a.pomf.se/uylgji.webm [20:02] <wm4> it works with ffplay, but not vlc or mpv (they show massive blocking in most frames) [20:03] <wm4> if I use libavformat's demuxer with mpv, it works, same if I enable libavformat video packet parsing in mpv [20:03] <ubitux> frame 17, 64, 133 (and more later) have no PTS set [20:03] <wm4> the file was produced by ffmpeg cli apparently, so this could be a case where ffmpeg produces files only ffmpeg can read [20:05] <wm4> ubitux: to me it looks like every demuxer-level packet has a pts set [20:05] <wm4> the missing pts probably comes from the parser splitting the packets or so [20:06] <wm4> in fact, matroska packets can't have no pts [20:07] <BBB> wm4: was it produced using transmuxing? [20:07] <BBB> (-vcodec copy) [20:10] <wm4> asked the user, but no reply yet [20:16] <wm4> BBB: the user didn't create the file, so it's unknown how it was created [21:32] <wm4> BBB, ubitux: also the file plays when using libvpx-vp9 as decoder [21:33] <wm4> without going through extra parsing [21:34] <nevcairiel> the parser is mandatory for the vp9 decoder, as its required to split the vp9 "super-frames" into individual frames [21:34] <nevcairiel> libvpx probably handles this internally [21:35] <wm4> that pretty much goes against the spirit of matroska [21:36] <nevcairiel> what does matroska have to do with that [21:37] <wm4> it's the container format [21:37] <nevcairiel> and why would it care [21:38] <nevcairiel> the super-frames were intentionally designed to make handling easier for containers, so that every container packet produces a output frame [21:38] <wm4> and why does the vp9 decoder not eat these frames? [21:38] <nevcairiel> if they would not exist, you would have frames which never produce any output, messing with timestamps [21:38] <wm4> *packets [21:38] <wm4> well, the sample file already has problems with timestamps [21:39] <nevcairiel> thats probably the parser assigning the packet timestamp to the wrong frame after splitting [21:40] <nevcairiel> anyway, as far as I understood, it was pulled out of the decoder to allow frame-threading, can't properly frame thread if one packet contains more then one frame [21:40] <cone-129> ffmpeg.git 03Michael Niedermayer 07master:ebfe154bd522: avcodec/apedec: tmpk==32 is not supported, prevent undefined behavior [21:40] <cone-129> ffmpeg.git 03Michael Niedermayer 07master:68de2115ca1a: avformat/tee: print errors for each failed bitstream filter [21:40] <cone-129> ffmpeg.git 03Michael Niedermayer 07master:9b1d7d4fd38f: avformat/oggparsecelt: fix memleak [21:40] <nevcairiel> in short, want to decode vp9, run the parser first [21:40] <wm4> then parsing should have been put into libavcodec generic code [21:44] <nevcairiel> not really, its your responsibility to send the decoder data it understands, if for example some demuxer doesn't properly re-assemble h.264 frames, but sends it one 188 byte TS chunk at a time, you can't expect the decoder to try to fix it for you. [21:45] <nevcairiel> if you know that your demuxer doesn't do it properly, thats what the parsers are for :) [21:46] <nevcairiel> (although there may be a bug when remuxing with ffmpeg that it runs the parser over vp9 and breaking the super-frames apart and muxing the result) [21:48] <nevcairiel> I admit that it may have been nicer for the user if the decoder handled these internally, but I also see the issue that it poses with frame threading [21:49] <wm4> libavcodec/utils.c could do the parsing [21:50] <nevcairiel> if someone ever invents a high level API, it could, but the low level we have right now should not [21:50] <wm4> anyway, the parser still needs to be fixed to output correct timestamps [21:51] <wm4> currently using the parser+vpx gives worse results than just vpx... [21:51] <nevcairiel> worst thing that happens right now is that you end up without a timestamp on the super-frame (as the timestamp was assigned to one of the non-displaying frames), that shouldn't break any sane playback setup [21:59] <BBB> wm4: so the reason we put it in a parser is the same as the mpeg video decoder (1/2, not 4/h264) [21:59] <BBB> wm4: it makes design of the decoder easier [21:59] <BBB> wm4: in this case, the easy thing was multi-threading [21:59] <wm4> I can understand that [21:59] <BBB> wm4: I could not design that easily if the parsing was in the decoder [21:59] <BBB> it sucks, I get that, I really do [21:59] <BBB> but the tradeoff of not having effective frame-my was worth the suckage [22:00] <BBB> frame-mt [22:00] <wm4> but it's a bit of a problem when the packet format is suddenly changed or constrained (e.g. vpx accepts the "full" packets just fine) [22:00] <BBB> yeah... we should have files in fate that test that [22:00] <wm4> so I see the case for doing parsing in the generic libavcodec code (just like libavformat uses the parser) [22:00] <BBB> so implementors like vlc can easily test that [22:00] <BBB> it's a layering issue [22:01] <BBB> parsing in generic libavcodec code has the same issue as doing it in the decoder [22:01] <BBB> the parsing needs to be done before you call avcodec_decode_videoX() [22:01] <BBB> so that each packet causes one avcodec_decode_videoX() [22:01] <BBB> packet being in this case 1 frame [22:01] <wm4> true, the current API couldn't really handle outputting multiple frames per packet [22:02] <BBB> sadly... [22:02] <BBB> I mean, that's a known issue, this isn't new [22:02] <BBB> like I said, mpeg 1/2 video has this issue [22:02] <BBB> divx in avi had this issue also if you enabled b frames [22:02] <BBB> wasn't that called packed b frames [22:02] <wm4> the other thing is, why does matroska contain "full" packets? [22:03] <wm4> it should contain one packet per frame - so no parser should be necessary [22:03] <wm4> and where does the parser get the missing timestamp from anyway? [22:04] <wm4> so I think the file might have been incorrectly muxed [22:04] <wm4> though I don't know what the webm spec says about this [22:05] <BBB> no, vp9 actually wants it this way [22:05] <BBB> so do you remember packed divx b frames? [22:05] <BBB> now consider the famous libvpx alt-ref frames [22:06] <wm4> urgh [22:06] <BBB> they're invisible frames, not ever output by the decoder, placed like 10-15 frames in the future [22:06] <BBB> to get a b-frame like benefit in a different way [22:06] <BBB> so if you make that a frame, you have 16 packets for each 15 frames [22:06] <BBB> people *hate* this about vp8, you should see trollflamefests no mplayer-devel about this [22:06] <nevcairiel> vp8/9 really hates timestamp re-ordering, so they come up with alternate ways to be annoying :) [22:06] <BBB> it's hilarious [22:06] <BBB> so, they decided to merge the arnr (invisible frame) with the next visible frame [22:07] <BBB> so it's one-packet-in one-frame-out [22:07] <BBB> that sucks for decoders, because now packets contain two frames [22:07] <BBB> I mean, it's not truly 2 frames, you output only one, but you have to decode two sequential frames, which makes frame-my between the two impossible [22:07] <BBB> that sucks in so many ways [22:08] <wm4> so, I get that there's a frame that should never be displayed (whether it's a "real" frame or not) [22:08] <BBB> so I split outside codec layer [22:08] <BBB> yeah [22:08] <BBB> it can be a real frame [22:08] <BBB> then a later frame is just a "take the previous one" reference [22:08] <BBB> like a b-skip [22:08] <wm4> still, the decoder seems to output it... or lose the timestamp, or similar [22:08] <BBB> no the decoder is doing the correct thing, don't worry [22:08] <BBB> but the decoder doesn't know how to split [22:09] <wm4> if you run ffprobe -show_frames on the sample frame, you'll see that some frames are missing timestamps [22:09] <BBB> it expects something else to have done that [22:09] <nevcairiel> the way the parsers work today is that when they get a timestamp and a packet with multiple frames, they assign the timestamp to the first frame in the packet [22:09] <nevcairiel> now if the first of these frames is an invisible one, the timestamp is simply lost [22:09] <BBB> that could be related yes [22:10] <wm4> so ideally, the parser would return whether a frame has a timestamp or not [22:11] <wm4> well the parser API is confusing [22:11] <wm4> I don't even know how it's supposed to return timestamps or other additional info... [22:11] <nevcairiel> it doesnt return it, you have to get the info from the struct [22:12] <wm4> oh, I see [22:12] <wm4> wonderful [22:12] <nevcairiel> in any case, what the parser does is correct in the generic case, it doesn't know that the frame it just split is never going to be shown and should not have a timestamp assigned [22:14] <nevcairiel> the entire parser concept is one of the areas which was never revised or cleaned up, and its just not very flexible [22:28] <BBB> the parsing could certainly use a cleanup [22:28] <BBB> "this frame is invisible and thus has no timestamp" would be very useful information [22:29] <BBB> but that's hard mixing-wise, because the muxer has to unparse this again [22:29] <BBB> (note that we don't do that, so transmuxing is likely broken ATM for vp9) [22:29] <BBB> I've had that on my list ever since I split it out but I'm just not getting to it :( [22:32] <cone-129> ffmpeg.git 03Michael Niedermayer 07master:24725f8e096b: avformat/matroskaenc: fix indention level [22:32] <cone-129> ffmpeg.git 03Michael Niedermayer 07master:66e30a2e65e8: avformat/mpegtsenc: check avformat_new_stream() return [00:00] --- Sun Apr 27 2014

1 0

ffmpeg.log.20140426
by burek 27 Apr '14

27 Apr '14

[01:35] <Moonlightning> I'm trying to extract the audio from an mp4 video, but it seems I'm missing an encoder. [01:35] <Moonlightning> I'm on Ubuntu 12.04; I believe ffmpeg was installed with the OS [01:36] <c_14> In that case you're probably using libav, see #libav for help. [01:36] <c_14> Or download a static ffmpeg build. [01:36] <c_14> Or compile it yourself. [01:37] <c_14> Options, options, options [01:38] <Moonlightning> Thanks [01:40] <diesel420> static ftw [02:23] <relevart> I'm streaming using ffmpeg, and get "PES packet size mismatch" warnings from time to time. I'd like to filter the packet that generates these warnings but I can't find them using pkt->flags & AV_PKT_FLAG_CORRUPT [02:23] <relevart> pls help! [04:57] <alexanderino> Greetings. I would like to report a potential bug: the ffmpeg implementation of vorbis decoding does not work properly [or at all] with files created with older encoders. For example, I have many files with 'vorbis_vendor = Xiphophorus libVorbis I 20020408'. foobar2000 1.3.2 [which uses the ffmpeg library] refuses to play them, while older 1.x versions causes a warbling distortion. [04:57] <alexanderino> please let me know if there's anything i can do to help [04:59] <klaxa> you can upload a sample and file a bugreport on the ffmpeg bugtracker: http://ffmpeg.org/bugreports.html [05:01] <alexanderino> Thank you, klaxa. Shall do. [05:02] <alexanderino> I only have full songs. Will this be an issue? [05:02] <klaxa> not at all i think [05:02] <alexanderino> ok, good [05:02] <klaxa> thanks for bringing this up btw, i bet you are not the only one having this issue [05:03] <alexanderino> indeed [05:03] <alexanderino> i was chatting with the foobar2000 devs, they pointed out that it has to do with the ffmpeg library having partial support for libvorbis [05:03] <alexanderino> with older versions that do not use ffmpeg [0.666, 0.8.3], the songs play fine [05:04] <alexanderino> same with XMPlay 3.2, but not 3.8 [05:05] <alexanderino> i'll of course include this in the report, but foobar2000 1.3.2 [latest version] outright refuses to play the file. Here is the console output: Unable to open item for playback (ffmpeg: could not open the decoder): "O:\music\Death\(1993) Individual Thought Patterns\01 - Overactive Imagination.ogg" [05:21] <alexanderino> tried ffplay.exe, this is the result: [05:21] <alexanderino> [vorbis @ 00000000044f0260] partition out of bounds: type, begin, end, size, blocksize: 2, 0, 2080, 32, 1024 [05:21] <alexanderino> [vorbis @ 00000000044f0260] Vorbis setup header packet corrupt (residues). [05:21] <alexanderino> [vorbis @ 00000000044f0260] Setup header corrupt. [05:22] <alexanderino> with a recently encoded file, this is output: [ogg @ 000000000453ef60] 1912 bytes of comment header remainf=0/0 [06:12] <alexanderino> report created: https://trac.ffmpeg.org/ticket/3590 [06:13] <alexanderino> the smallest file is over 4 MB, so I have uploaded the sample via FTP with a text file describing it [06:13] <alexanderino> now i shall email the list [06:26] <alexanderino> is ffmpeg-user the correct list to send it? [10:33] <TheSchaf> -_- i have some videos that have a 1 pixel border on the left side [10:34] <TheSchaf> how do i remove that while keeping the same resolution in the best way? [10:34] <TheSchaf> i guess if i rescale the video quality will go down? [10:35] <TheSchaf> is there a way to copy the line next to the border over the border with ffmpeg? [15:20] <qeed> i saw a ffmpeg post saying a person was trying to add protracker mod support in gsoc 2010, did that go anywhere? i tried using ffmpeg ona a mod file and it says Invalid data found when processing input [15:59] <spaam> qeed: it was never commited to master :'( [15:59] <qeed> why not [16:02] <spaam> because it needed some fixes and it was never fixed.. :/ [16:03] <spaam> but one source say that you can compile with libgma or libmodplug to play those files. but yeah. that 3rd party. [16:03] <qeed> i just used xmp [16:04] <spaam> okey [17:28] <wizbit> does anybody remember the name of tool what lets you adjust webcam settings on the terminal? [17:28] <wizbit> my webcam is showing in black and white, but i used a terminal tool to change it to colour, i cant remember what it was [17:39] <revolver> hi people <3 [17:40] <revolver> i was looking for a way to record audio directly from the audio card (recording the sound that is currently being reproduced) [17:40] <revolver> I do that using Audio Hijack in MacOS and Audio Recorder in Windows [17:40] <revolver> How could I do the same in a Linux enviroment? does ffmpeg have the proper tools to do that? [17:49] <klaxa> you audio "driver" will have to take care of that, if you are using pulse it's pretty simple, i think it's possible with alsa, no idea how to do it with alsa really [17:50] <klaxa> on pulse you can open the pavucontrol gui (if you don't have it, you can install it) record with ffmpeg using: ffmpeg -f alsa -i pulse -c:a libvorbis out.ogg and in the gui select "monitor of <soundcard here>" as the source for the ffmpeg recording stream in the recording tab [19:42] <znf> Hello. I have a question related to libx264. I'm somehow getting HUGE files for something that is basically a still image with a "showwaves" filter applied on the bottom of the image. I thought that x264 should be a lot more effective at this. Could someone tip me off as to how I could reduce the filesize? I somehow think that it shouldn't require ~4000kbps for something as simple as this [19:42] <znf> I'm running this command: [19:42] <znf> tools\ffmpeg.exe -y -i temp\audio.mp3 -loop 1 -i temp\canvas.png -i temp\annotated.png -filter_complex "[0:a] showwaves=size=1280x100:mode=line:r=25 [wave];[1:v][wave] overlay=y=H-h:eval=init[comp];[comp][2:v] overlay=eval=init" -shortest -acodec copy -vcodec libx264 -pix_fmt yuv420p -preset ultrafast -tune stillimage -crf 19 -movflags faststart "videos\WANDERHOUSE-SUGAR.mp4" [19:47] <klaxa> well, try increasing the crf value [19:48] <klaxa> 19 is pretty high quality [19:48] <znf> I did, even with 31, the file-size is still huge considering the video content [19:48] <sacarasc> Use an actual bitrate, maybe? [19:48] <znf> ~25minute audio file results in something like ~400mb video size [19:54] <blippyp> znf: your problem is that you're using an ultrafast preset - this will encode the file very fast, but will create large files - change it to veryslow, slow or just leave it out entirely - You'll notice large differences in your file size [19:54] <znf> I'll try, thanks [19:54] <klaxa> ah yeah didn't see that even [19:54] <blippyp> keep in mind though that you are still creating a video file - so the file is going to be much larger than your audio file, and it will take a lot longer to encode [19:56] <blippyp> if you want to keep your video quality to near 'original' I would change your crf to 17 (this is what I always use) if you plan on re-encoding it again for something else you might want to go lower even. [19:56] <znf> yeah, I know that [19:56] <znf> I just thought that since less than 10% of the image changes every frame, it shouldn't really be that big [19:57] <blippyp> no, it doesn't work like webm [19:57] <blippyp> it will still be a large file [19:57] <blippyp> but using a different preset other than ultrafast will show significant differences in your file size nonetheless [19:58] <znf> mhm, I see... though 30fps encoding vs. 130fps... :-/ [19:58] <blippyp> you might be happier using webm for what you want [19:59] <znf> but webm is slow as molasses :( [20:00] <blippyp> it's not that bad - you'll get a much bigger investment in your file size since that's what you're complaining about [20:00] <blippyp> it will do what you wanted [20:00] <znf> just trying to find a sweet spot, mostly [20:00] <blippyp> seriously, if you're using a still image for the video webm is the way to go [20:02] <znf> blippyp, but I don't want to encode stuff at 25fps, for example. Generate a video for a 60 minute song, that's one hour of encoding [20:02] <blippyp> then don't? [20:02] <blippyp> change the framerate to whatever you want...??? [20:03] <znf> the showwaves filter looks bad at below 20fps, I noticed [20:03] <blippyp> what resolution is the video? [20:04] <znf> 720p [20:04] <blippyp> no matter what you're going to have to give up something [20:04] <sacarasc> znf: What's CPU do you have? [20:04] <znf> seems crf=21 with preset=fast is still decent [20:04] <znf> sacarasc, core i5 4440 [20:05] <blippyp> with x264 - it will encode faster (but not really that much faster) and you'll end up with much larger file size - use webm and it will encode a little slower, but you'll end up with MUCH smaller file sizes... [20:05] <sacarasc> And lower quality. [20:05] <blippyp> you might be able to play with the crf since the video isn't changing that much [20:05] <znf> hmm, my build doesn't seem to have webm support [20:05] <znf> does webm support yuv444p? [20:06] <klaxa> no [20:06] <klaxa> vp8 only supports yuv420p [20:06] <znf> crap :( [20:06] <klaxa> also, fast is still pretty bad [20:06] <klaxa> try medium or slow [20:06] <znf> I'm getting ~1.2mbit/s at "fast" [20:06] <klaxa> you should generally start with medium [20:07] <znf> also, does webm support mp3 audio? [20:07] <klaxa> if you think you can go slower, go as slow as possible [20:07] <klaxa> no [20:07] <klaxa> webm supports opus and vorbis [20:07] <znf> then that's out of the question :-/ [20:08] <znf> though, I still want to give it a try [20:08] <znf> anyone knows of an ffmpeg build for windows with libvpx support? [20:09] <blippyp> try the static build on ffmpeg - the linux version has it [20:09] <znf> ah, it seems zeranoe's has it now, too [20:09] <znf> last time I checked it didn't [20:09] <znf> it lists support, anyway [20:11] <znf> yeah... I'm getting 8 fps with webm [20:12] <blippyp> let it finish though - so you can see the benefits... ;) compare it with a x264... [20:12] <znf> woah... [20:13] <znf> default flags (ie: no flags passed to the decoder) [20:13] <znf> == 3 fps [20:13] <klaxa> are you using vp8 or vp9? [20:13] <znf> libvpx [20:14] <klaxa> vpx can encode both, vp8 and vp9 [20:14] <znf> I'm not sure, what's the default? [20:15] <klaxa> i would guess vp8 because it's less complex [20:15] <klaxa> what does ffmpeg print? [20:15] <klaxa> also i think vp8 is single threaded by default too [20:15] <klaxa> because multi-threaded encodes with vp8 are non-deterministic [20:15] <znf> vp8 [20:15] <blippyp> yeah - you'd want to set the -threads [20:16] <znf> setting -threads crashes ffmpeg :-/ [20:16] <znf> but this looks horrible http://i.imgur.com/vhdK2gS.jpg [20:16] <klaxa> in how far? [20:17] <znf> in me pressing enter :> [20:17] <blippyp> not in linux it doesn't.... [20:17] <klaxa> "it crashes" is not really a good description [20:17] <klaxa> does it segfault? [20:17] <klaxa> does it tell you the arguments are invalid? [20:17] <blippyp> show your command - paste it to pastebin or something [20:17] <znf> no, it crashes with "ffmpeg has encountered an error and needs to be closed" [20:18] <znf> tools\ffmpeg.exe -y -i temp\audio.mp3 -loop 1 -i temp\canvas.png -i temp\annotated.png -filter_complex "[0:a] showwaves=size=1280x100:mode=line:r=25 [wave];[1:v][wave] overlay=y=H-h:eval=init[comp];[comp][2:v] overlay=eval=init" -sho [20:18] <znf> rtest -acodec libvorbis -vcodec libvpx -crf 4 -threads 4 "videos\WANDERHOUSE-SUGAR.webm" [20:18] <znf> crap [20:19] <blippyp> I don't see anything wrong with that - you should set a bitrate though - I think crf still wants a bitrate (-b:v) or it won't work very well [20:19] <znf> if I use -vcodec vp9, it doesn't crash [20:20] <klaxa> crf 4 is pretty high too btw [20:20] <klaxa> vp9 will be slow as hell [20:20] <blippyp> vp9 will be much slower than 8 though [20:20] <klaxa> if you run x264 at "fast" and complain about speed, vp9 is not for you [20:20] <znf> well, vp8 crashes when passed threads [20:20] <blippyp> yeah crf 4 is low - with mostly a still background you should be able to get away with much higher value I'd think [20:21] <znf> and even with -crf 4, the quality is incredibly crap [20:21] <znf> erm, isn't lowest == better quality? [20:21] <blippyp> that's because you didn't set a bitrate [20:21] <klaxa> pretty much yeah [20:21] <blippyp> it's defaulting to some crappy value [20:21] <znf> I just set a -b:v 2000k [20:21] <znf> and it's still low :-/ [20:21] <blippyp> that should work - I'd bet you can set it much lower though [20:21] <klaxa> also on my server with an i7 2600 at 3.4 ghz it took 30 minutes to encode a 90 seconds video in 1080p [20:22] <klaxa> so there's some benchmark for you, not sure you want vp9 really [20:22] <znf> then I don't really see the point in webm :-/ [20:22] <blippyp> the final file size [20:22] <blippyp> that's the point [20:22] <klaxa> the point in webm is compatibility across all platforms [20:22] <blippyp> if it's not that important to you than x264 is fine - and faster [20:23] <klaxa> x264 gives better results than vp8 [20:50] <ChocolateArmpits> Hello, is there any command line media player that could be output piped to ffmpeg ? [21:13] <klaxa> i think every player related to mplayer can dump the stream [21:13] <klaxa> you can also use ffmpeg for decoding a stream [21:59] <blippyp> znf: I did a test once to compare putting a smaller video on a much larger black background with webm to test if it would change the file size: And it didn't (or at least very little). However, I mistakenly always assumed that because those pixels did not change that this would also apply with a static 'picture' background. I have been testing it out and it appears I was wrong about that. WebM is definately not what you want - I apologize f [22:20] <ChocolateArmpits> klaxa, I was looking to run on Windows; I want to pipe the output because ffmpeg by itself throws a lot of errors when trying to parse the broken AVI files that I want to fix. FFplay, VLC and other players have no playback problems though. [22:30] <jarainf> ChocolateArmpits, how would ffplay manage to playback without any problems while ffmpeg throws errors? [22:30] <jarainf> Are the errors fatal? [22:31] <jarainf> If not, I doubt you'd get better results using a player to pipe it to ffmpeg. VLC is a beast and might be able to save something, but that's about it... [22:31] <ChocolateArmpits> jarainf, throws a bunch of errors during encoding I think [22:31] <ChocolateArmpits> The files were recovered from a broken sd card [22:31] <jarainf> Could you paste it's output? [22:31] <ChocolateArmpits> Sorry, not at work [22:32] <jarainf> What are the errors about? [22:34] <ChocolateArmpits> Sorry, jarainf, don't remember them exactly. I was only ready to solve it by piping output from VLC, but there's not much concrete information about that. Wasn't preparing to write down the errors [22:35] <ChocolateArmpits> Avisynth reads the files also [22:36] <ChocolateArmpits> If the command line for VLC won't work, then it's Avs and MediainfoCLI to extract codec information for me I guess [00:00] --- Sun Apr 27 2014

1 0

ffmpeg-devel.log.20140425
by burek 26 Apr '14

26 Apr '14

[00:54] <cone-441> ffmpeg.git 03James Almer 07master:5ac10d40fb9b: x86/mpegaudiodsp: define apply_window_mp3 as SSE [01:03] <cone-441> ffmpeg.git 03Janne Grunau 07master:a88e1d1c598e: lavu: add CHK_OFFS as AV_CHECK_OFFSET to check struct member offsets [01:04] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:06e664366a66: Merge commit 'a88e1d1c598e641eecd5d43730211d91c82787c6' [01:18] <cone-441> ffmpeg.git 03Janne Grunau 07master:cae8df78759c: lavr: define ResampleContext in resample.h [01:19] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:26953ed2e39d: Merge commit 'cae8df78759c2e69257f7fe58842f34c0d98a7ec' [01:34] <cone-441> ffmpeg.git 03Janne Grunau 07master:a24a252709dd: aarch64: NEON optimized FIR audio resampling [01:34] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:e32fc9b45b11: Merge commit 'a24a252709dd38f12aa4929ce4981f87091a5113' [01:40] <cone-441> ffmpeg.git 03Derek Buitenhuis 07master:8de77b665d2a: fate: Add fic-in-avi test [01:41] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:817627d92538: Merge commit '8de77b665d2a2f1cd560d2183fd4664298b30715' [02:12] <cone-441> ffmpeg.git 03Carl Eugen Hoyos 07master:eeee59ba4d48: Never write 0 as maximum bitrate for asf files. [02:12] <cone-441> ffmpeg.git 03Carl Eugen Hoyos 07master:a19bcf4ee8d9: Fix libpostproc compilation with !HAVE_6REGS. [02:12] <cone-441> ffmpeg.git 03Carl Eugen Hoyos 07master:9cc4bc973c20: Fix vf_eq.c and vf_eq2.c compilation with !HAVE_6REGS. [02:12] <cone-441> ffmpeg.git 03Carl Eugen Hoyos 07master:ced0d6c14d1a: Use correct msvc type specifiers for ptrdiff_t and size_t. [02:12] <cone-441> ffmpeg.git 03Carl Eugen Hoyos 07master:18e7e21e2fb1: Enable muxing ac-3 in caf. [02:13] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:e148a5820dc5: Merge remote-tracking branch 'cehoyos/master' [02:47] <cone-441> ffmpeg.git 03Ben Avison 07master:270cede3f377: h264: Move search code search functions into separate source files. [02:47] <cone-441> ffmpeg.git 03Ben Avison 07master:9d8ecdd8ca6d: vc-1: Add platform-specific start code search routine to VC1DSPContext. [02:47] <cone-441> ffmpeg.git 03Ben Avison 07master:a0d7f9ec9a10: vc-1: Optimise parser (with special attention to ARM) [05:15] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:6e5cce1cbe54: configure: allow overriding ranlib [05:30] <cone-441> ffmpeg.git 03Y.C. Liu 07master:cebe06a0bf19: avutil/opencl: fix a segmentfault in libavutil/opencl.c [07:07] <cone-441> ffmpeg.git 03James Almer 07master:25d5ea6d5a08: lavu: add LOCAL_ALIGNED_32 [07:07] <cone-441> ffmpeg.git 03James Almer 07master:c7b089048dbe: vp9: use LOCAL_ALIGNED_32 for left/top intra_pred pointers [07:33] <ubitux> jamrial: you're going to do some avx2 for vp9? [07:53] <jamrial> Wrote a couple trivial intra_pred 32x32 functions, which is how i found out the alignment problem [07:57] <jamrial> Although even after the above patches a (top) is still unaligned for some reason [07:57] <jamrial> l (left) is ok now [08:00] <jamrial> dst also seems to be unaligned [08:00] <nevcairiel> sounds like it may be inherently unaligned [08:01] <jamrial> It works wonders with movdqu, but if that's needed then one might as well just use the xmm version [08:02] <nevcairiel> some of the xmm versions use movu in some places because its just accessing odd offsets [08:05] <wm4> can ffprobe hexdump packets yet? [08:05] <jamrial> The ones i ported to avx2 don't. A couple others do, though [08:05] <ubitux> wm4: iirc yes but i may be wrong [08:06] <wm4> oh, -show_data [08:06] <wm4> I made the mistake trying to read the ffprobe help output [08:25] <jamrial> ubitux: here's what did if you're curious https://github.com/jamrial/FFmpeg/commit/400445b0ab1efc933995852354269972ac… [08:27] <jamrial> Seems to work as is, but the movdqu galore is probably far from good [08:41] <wm4> why does ffmpeg still have libpostproc in its repo? [08:42] <wm4> isn't there a separate repo for libpostproc now? [08:42] <wm4> and why does the separate repo not have all features the ffmpeg libpostproc has? (at least CPU autodetection is missing) [09:28] <j-b> good mornin [09:30] <ubitux> michaelni: it seems my ip is blacklisted from gmx, that's the reason i can't send you an email on your address [09:56] <ubitux> ok that's probably because i don't have a valid reverse dns... fuck that shit [09:56] <nevcairiel> some mail servers are rather picky about that [09:57] <ubitux> well i have an spf record, it should be enough [13:22] <BBB> ubitux: so far I've found that it's coefficient-coding related, chroma only, only affects 32x32 luma-coded blocks (so 16x16 chroma-predicted blocks with a 8x8 transform, I think) [13:22] <BBB> ubitux: not a race condition, so even if frame 1 completes entirely before I start frame 2, it's an issue, but indeed goes away when you use -threads 1 [13:22] <BBB> ubitux: but that's as far as I got... weird stuff [13:45] <BBB> oh, sorry, 16x16 transform obviously [13:45] <BBB> anyway [13:48] <BBB> hum, looks like uveob is wrong [13:50] <BBB> ah there it is [13:50] <BBB> that's stupid [13:52] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commit/6d69f9f37689c999815a65a2d99999fad3… [13:52] <BBB> michaelni: for you to merge also ^^ [13:53] <BBB> my git send-email isn't working so can't send to ML right now, I probably broke something when upgrading my macports [14:12] <BBB> ah fixed [14:12] <BBB> yay [14:12] <ubitux> BBB: i don't get why threading is relevant; can you elaborate? [14:13] <BBB> neither do I [14:13] <BBB> I think what happens is that in the single-threaded case, the upper byte from the previous run is retained [14:13] <BBB> i.e. we never write the value, but we read it [14:13] <BBB> so we take it from the previous thread [14:13] <BBB> where it may or may not be correct [14:13] <ubitux> ah, ok [14:13] <BBB> apparently it is correct here o_o [14:14] <BBB> in the multi-threaded cases, we start from uninitialized memor [14:14] <ubitux> does it fix -02 as well? [14:14] <BBB> probably [14:14] <BBB> this should affect all low-q (non-zero) tests [14:14] <BBB> possibly all the way up to 5 or 6 or so [14:14] <ubitux> i mean fate-vp9-00-quantizer-02 [14:14] <BBB> yeah, I know, it should fix it [14:14] <ubitux> ok ok :) [14:15] <BBB> works here now, yes [14:15] <BBB> don't know if it broke before, but it probably did [14:15] <ubitux> cool, nice [14:15] <michaelni> BBB, should i merge 6d69f9f37689c999815a65a2d99999fad3a41705 or apply the patch from the ML ? [14:15] <BBB> oh actually single-threaded is easier [14:15] <BBB> because it doesn't use 2-pass decoding [14:15] <BBB> so it takes the rob values from the previous block [14:16] <BBB> which for low-q values is the upper bits of the previous block, and that should always be "high" [14:16] <BBB> so that's why that works in single-threaded mode [14:16] <BBB> michaelni: they should be identical, so up to you [14:16] <ubitux> ok :) [14:16] <michaelni> i already have the merge locally so ill go with that then [14:17] <cone-743> ffmpeg.git 03Ronald S. Bultje 07master:6d69f9f37689: vp9: write uveob as 16-bit value for 16x16/32x32 transforms. [14:17] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:2f2629c8700b: Merge commit '6d69f9f37689c999815a65a2d99999fad3a41705' [15:12] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:abbcc6b26b4a: avcodec/utils: use av_malloc(z)_array() [15:12] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:681a5b8d6f35: avcodec/ttaenc: use av_malloc_array() [15:12] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:92cc6d5163cd: avcodec/mdct_template: Use av_malloc_array() [16:54] <cone-743> ffmpeg.git 03James Almer 07master:cdac3ab59f3c: swresample: add swri_resample_double_sse2 [19:58] <cone-743> ffmpeg.git 03Don Moir 07master:62056d09b13c: avformat/avidec: skip len=0 entries from the index [20:15] <Daemon404> does anyone have an account on the gcc bugtracker [20:15] <Daemon404> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 is fixed [20:15] <Daemon404> but it hasnt been backported to the 4.9 branch [20:16] <Daemon404> it might nt be backported at all to 4.9 (making 4.9 useless for ffmpeg) if someone doesnt poke it [20:16] <Daemon404> and ask [20:17] <Compnn> michael does [20:17] <Daemon404> ubitux might [20:17] <Daemon404> maybe jamrial [20:17] <Daemon404> or reimar [20:17] <Compnn> whoever else commented on that gcc bug ffmpeg triggered [20:18] <jamrial> "Target Milestone: 4.9.1" [20:18] <jamrial> i want to believe it's going to be backported sooner or later [20:19] <Daemon404> ok there mulder [20:19] <ubitux> i don't have an account on that bugzilla [20:19] <Daemon404> i only have one on llvm's [20:19] <jamrial> neither do i [20:20] <jamrial> cehoyos does, though [20:20] <ubitux> carl certainly has one, and since he's often reading the irc logs he might do it [20:20] <jamrial> he reported the duplicates of this bug [20:20] Action: Compnn waves to carl [20:20] <Daemon404> did someone update our trac with the link to the commit/bug? [20:20] <ubitux> iirc yes [20:21] <ubitux> by carl himself [20:21] <ubitux> https://trac.ffmpeg.org/ticket/3559#comment:15 [20:34] <Compnn> "The function looks suspicious and I'm not sure if the code is valid." [20:34] <Compnn> :D [20:34] <michaelni> i might have an account but if so i didnt use it for many years and dont remember the pw [20:37] Action: Compnn wonders how many ffmpeg testcases in gcc testsuite [21:02] <cone-743> ffmpeg.git 03Aidan Skinner 07master:802385dbc2c5: mov: Write prof section of tapt tag [21:02] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:944a744bf585: Merge commit '802385dbc2c57abd76f6a00e32f3df35e9526c08' [21:09] <llogan> hell, i can make an account, and regurgitate whatever you want if evetyone else is too lazy to do it [21:12] <Daemon404> :P [21:13] <Daemon404> i have too many bug tracker accounts [21:13] <Daemon404> one-off ones [21:22] <jamrial> there [21:23] <jamrial> posted a comment [21:32] <llogan> thanks, jamrial [21:52] <jamrial> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902#c33 and the reply [21:57] <jamrial> so yeah, wasted time. but at least now i have a gcc bugzilla account in case i need to actually report something :P [21:59] <Daemon404> jamrial, kind of a dickish response from gcc guy [21:59] <Daemon404> but :foss: [22:06] <cone-743> ffmpeg.git 03Miles Gould 07master:99e22b785917: mov: Emit the correct tags for clcp tracks [22:06] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:c9e0f7a080c1: Merge commit '99e22b7859177f6d3ed6121040924b337dce5497' [22:06] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:af165acefacd: avformat/movenc: dont store invalid tapt atom [23:18] <llogan> Compnn: how many beard inches (Bi) ago was that? [23:32] <Compnn> llogan : it was ... PRE BEARD! [23:33] <Compnn> or 5 P.B. [23:47] <cone-743> ffmpeg.git 03Michael Niedermayer 07master:e0e60c921133: avcodec/dpx: extract frame rate [00:00] --- Sat Apr 26 2014

1 0

ffmpeg.log.20140425
by burek 26 Apr '14

26 Apr '14

[00:02] <haptiK> okay so i actually moved all the configuration options on to one line [00:02] <haptiK> and it's still not showing up in ffmpeg -encoders | grep libx264 [00:03] <haptiK> after running the complete build script again [00:03] <haptiK> any idea what to try next? [00:04] <haptiK> I've seen something about libavcodec-extra-53 in some forums, but that appears to be ubuntu related [00:04] <haptiK> not to mention it looks like its for avconv not ffmpeg [00:06] <c_14> Could you paste the last ~2000 lines of the script output/the part which starts with install prefix up until the Creating config.mak, config.h, and doc/config.texi... ? [00:06] <c_14> Just so I can check the new configure output for ffmpeg [00:07] <haptiK> okay, i'll rerun it again because I didn't save to an output file. oops. [00:07] <haptiK> thanks for your time by the way [00:08] <c_14> No problem, I hope I can help. [00:45] <haptiK> c_14 what line am I looking for? [00:46] <haptiK> i just psated the whole thing again [00:46] <haptiK> im not entirely sure what you're looking for, i messaged you the link. i hope you don't mind. [00:46] <c_14> It's fine, though you might want to post it here in case other people want to check as well. [00:47] <c_14> Ok, according to the configure output libx264 has been compiled in and is also an encoder. [00:48] <c_14> What exactly was the problem again/have you tried encoding using -c:v libx264 again? [00:48] <haptiK> yes one second [00:50] <haptiK> http://pastebin.com/29ibfaig [00:51] <haptiK> that's basically what im dealing with (forgot the file extension in one of the commands) [00:54] <c_14> Normally after "configuration:" there should be a list of the config options, in this case the important one being --enable-libx264. I don't see that in the output for this paste. [00:55] <c_14> Does ffmpeg -version return anything for configuration: ? [00:55] <haptiK> checking [00:55] <haptiK> http://pastebin.com/WE2e09D0 [00:56] <haptiK> it doesn't appear to be there [00:56] <haptiK> again [01:00] <c_14> Is /root/bin in your $PATH ? [01:00] <c_14> Maybe try starting ffmpeg directly as /root/bin/ffmpeg [01:01] <c_14> (I'm just going to ignore the fact that you probably shouldn't be running ffmpeg as root here) [01:01] <haptiK> http://pastebin.com/9wgV2VdT [01:01] <c_14> /usr/local/bin is before /root/bin in the path. [01:02] <c_14> And since the skript went haywire a while ago, you have the old ffmpeg binary in /usr/local/bin [01:02] <c_14> So (I'm assuming) it's still executing that one. [01:02] <haptiK> http://pastebin.com/r9Rx3mGY [01:02] <haptiK> =D [01:03] <c_14> That looks much better. [01:03] <haptiK> \0/ [01:03] <haptiK> okay let me try to encode that [01:03] <haptiK> how would you suggest i remove the old version [01:03] <haptiK> so i don't have to specify the path [01:04] <c_14> You can either remove them manually (fun). Or enter the ffmpeg source directory, run ./configure and then make uninstall [01:05] <haptiK> okay thank you [01:05] <haptiK> i may have more question if you don't mind but not now [01:05] <haptiK> i need a break from this :) [01:06] <c_14> If I'm around and I can help, I will. [01:06] <jkli> hi all :) [01:06] <haptiK> thank you so much for your help and your time. it's been a long time since i've used irc, and its really great to know quality help is still out there. [01:06] <c_14> No problem. [01:07] <jkli> I finally got nginx-rtmp working, but the first seconds from the mp4 files are often green screens, after a few seconds the image turns out fine and when i seek back to the beginning, it is also fine again [01:07] <jkli> seeing that this channel has many video encoding pros, I was wondering what effect most likely causes those green screens in the initial loading [01:08] <jkli> oh all vids are encoding using ffmpeg and x264 newest build [01:08] <c_14> If I remember correctly, mp4 files have metadata spread throughout the file so the green screen could be due to the player not having enough metadata to play the file correctly yet, but I'm not entirely sure. [01:09] <c_14> But you might want to wait until somebody comes along who knows more about that sort of thing than me. [01:12] <jkli> well i encoded them with movflags faststart [01:12] <jkli> to move the index to the beginning [01:12] <jkli> shouldnt it move all metadata to the beginning as well? [01:15] <c_14> Well, there goes my idea. [01:18] <jkli> i read somewhere that greenscreens are caused by framedrops [01:19] <c_14> They can be, but that wouldn't explain why you're only getting packet loss in the first few seconds. [01:30] <haptiK> Does anyone know anything about GMP4 files? [01:30] <haptiK> [avi @ 0x386bd00] Could not find codec parameters for stream 0 (Video: none (GMP4 / 0x34504D47), 320x240, 419 kb/s): unspecified pixel format [01:37] <iive> haptiK: GeoVision Advance Mpeg4... you might have some luck if you find a way to force it as xvid [01:40] <haptiK> yes they are files from geovision [01:41] <haptiK> would you mind suggesting how to do what you describe? [01:41] <haptiK> also there is POS metadata which overlays the video i'd like to be able to keep that as well [02:04] <iive> sorry... maybe there is -fourcc option, i don't know. [04:43] <DrewM> When encoding to VP8 the wiki says you should both use CRF and also tell it to target a bitrate. Why is that? Is it because there are no ways to make the encoder move quickly or slowly as in X264? [07:31] <xecycle> Hi. I have an ASS subtitle with fancy effects, but it renders very slow when played. I tried burning it into video by ass filter, and it did work; but transcoding the original video is quite time consuming. Is it practical in this case to render the subtitle into a picture-based format and use it without transcoding the original video? [12:23] <termos> I created my own transcoder using libffmpeg, but when it's running it takes up 100% cpu on all cores. But the ffmpeg program only takes up about 40% on all cores. I haven't debugged that much yet but does anything come to mind to someone here? [12:24] <termos> They are both running main profile and fast preset on x264 with fdk_aac audio. [13:31] <superc2_> hi... still trying to get a very basic streaming server running... in the meanwhile removed avserver and downloaded the latest tarball of ffmpeg, compiled from sources [13:32] <superc2_> however when I try to stream a file to ffserver I get 'segmentation fault' [13:34] <klaxa> avserver is part of avconv, see #libav [13:35] <superc2_> yes... thats why I said that I REMOVED avserver [13:35] <klaxa> ah sorry [13:35] <superc2_> so I'm trying my luck with ffmpeg now [13:35] <klaxa> can you pastebin what you did? [13:37] <superc2_> http://pastebin.com/Ys1kQ005 [13:37] <klaxa> oh? that is weird [13:38] <klaxa> can you run that with valgrind? [13:38] <superc2_> basically I just followed this short howto: http://www.alkannoide.com/2013/07/04/play-with-ffserver-a-quick-overview/ [13:38] <klaxa> just prepend valgrind to the command, if you don't already have valgrind, install it [13:41] <superc2_> http://pastebin.com/UXZh9q6G [13:42] <klaxa> >Address 0x10 is not stack'd, malloc'd or (recently) free'd [13:43] <klaxa> this sure as hell doesn't look right [13:43] <superc2_> so maybe I shoulr try another tarball? [13:43] <klaxa> maybe compile from git source [13:43] <klaxa> if it still happens, file a bugreport [13:47] <superc2_> while I'm recompiling... actually is ffserver able to switch between multiple sources and generate new input sources (I think feeds) on the fly or by connecting to a mysql db? [13:48] <klaxa> good question, i don't know [13:48] <superc2_> so actually what I want to achieve is that there are multiple users sending a video stream to the server and then a software connects one of the feeds and switches it to an output stream [13:48] <superc2_> or is there a better solution to achieve this? [15:36] <artista_frustrad> I'm trying to convert a .VOB file to mp4 but the duration on the metadata is about 20 minutes short of the actual duration of the video. The converted video ends up being the size of the metadata duration. Is there a way to convert the video to the correct duration? [15:39] <blippyp> paste your exact command to pastebin.com or similiar site then post the link [15:40] <c_14> And all output [17:32] <Daghdha> Hello, i have a gif with 38 frames. If i convert it to seperate frames using ffmpeg.exe -i aa.gif f%4d.png i end up with 216 frames. The gif however only has 37 frames. How can i have it output the exact number of frames. I have other gif images that do go correct. I have opened the gif in Photoshopped and confirmed it indeed only has 37 frames. [17:33] <Daghdha> I am familiar with -r, but don't want to apply it to all gifs. I just want each frame stored in the gif once. [17:35] <robin___> Hello everyone. I am having troube understanding why a PCM Wav file with a duration of exactly 17 seconds, when converted to m4a/aac get a duration of 17.05 seconds and a start time of 0.046440 seconds. any help appreciated [17:40] <ubitux> Daghdha: -vsync vfr or something like that i suppose [17:41] <Daghdha> It's all spanish to me ubitux, i will have a look in the manual and check vsync info. thanks [17:41] <ubitux> juste add -vsync vfr to your cmd line [17:42] <Daghdha> i did, seems folden. Thanks :) [17:43] <Daghdha> ^golden [18:03] <stolenhubcaps> Is it possible to use ffmpeg to get video from v4l2 then reencode it into several formats for streaming? (mjpeg over http, some kind of html5 friendly format), and perhaps a couple resolutions? Ideally it'd be possible to turn off unused encoders if theres no viewers/etc [18:07] <randomguy123> yo, is there a way to stream theora/ogg from ffmpeg?? [18:10] <stolenhubcaps> ffmpeg seems to be like an octopus, it has lots of arms that can do cool stuff, but it seems to require some research to teach it to use those arms :( [18:13] <randomguy123> i see from wiki that ffmpeg isn't on the list of theora/ogg capable streamers: http://en.wikipedia.org/wiki/Theora#Streaming [18:14] <c_14> randomguy123: https://trac.ffmpeg.org/wiki/Streaming%20media%20with%20ffserver#StreamingT… [18:14] <randomguy123> i need to write some code to make it stream. On input I have either h264 or raw yuv. I have only like a day or two to do it. I'm more or less familiar with ffmpeg [18:15] <randomguy123> (libavcodec/avformat), but if I need to use vlc I'd like to find out before I start messing with ffmpeg [18:16] <stolenhubcaps> randomguy123: I'd check -codecs, i see D.V.L. theora Theora [18:17] <c_14> stolenhubcaps: Everything up to streaming yes. Streaming should work, but it depends a lot on your setup. [18:17] <randomguy123> what does D.V.L. mean? [18:17] <c_14> Decode Video Lossy [18:17] <randomguy123> decoder/video... ?? [18:17] <randomguy123> ah, ok [18:18] <randomguy123> no, i know that ogg/theora are obviously supported. The question is about streaming [18:18] <c_14> What do you mean with streaming, something like ffserver? [18:18] <randomguy123> i'm not familiar with ogg, but I think it's well designed for streaming. [18:19] <randomguy123> meaning like live tv stream, not simple playback of pre-recorded ogg file from disk over a network. [18:21] <c_14> ffmpeg can take input from a live source, encode it and then stream the output somewhere, but it can only stream it to a server it cannot act as the server itself. [18:21] <c_14> Do you have a streaming server (the thing the clients connect to) or do you need one? [18:28] <stolenhubcaps> c_14: Pretty much i have some software that can either use the v4l2 device or an mjpeg 'stream'. I need to be able to view the v4l2 video somehow and still feed that program. Never been able to get v4l2_loopback or such to work tho [18:29] <stolenhubcaps> git clone git://git.savannah.gnu.org/grub.git [18:34] <c_14> You can use ffmpeg to grab the v4l2 device, and then output it into a file or fifo so you can view the video while also outputting it to another output. Depending on how the program accepts input you should be able to get it to do what you want. [18:34] <c_14> try looking at: https://trac.ffmpeg.org/wiki/How%20to%20capture%20a%20webcam%20input and https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [18:41] <stolenhubcaps> thanks [22:08] <haptiK> hello. i read that in order to force ffmpeg to pretend the file is different than what it really is i can use -vtab or -tab:v and then specify the format? I believe this forces a different "fourcc"? Is this correct? I've tried doing this, but without mucho success [22:13] <llogan> haptiK: i think you mean -vtag [22:15] <haptiK> okay let me look into that [00:00] --- Sat Apr 26 2014

1 0