Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2013

1 participants
60 discussions

ffmpeg-devel.log.20130629
by burek 30 Jun '13

30 Jun '13

[00:11] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:804c7b2c62a6: udp: Fix receiving large udp packets [00:12] <michaelni> superware, please try if the issue is fixed [00:29] <superware> michaelni: ok, but I need a win32 build [00:31] <michaelni> no hurry, if you cant build one yourself you can wait for a new zeranoe build to appear [00:32] <superware> daily? [00:33] <michaelni> i think so [00:35] <superware> ok great Michael, thank you very much for the great help (and project) [00:35] <superware> I'll report here, tomorrow I guess [00:36] <superware> bye [00:51] <cone-868> ffmpeg.git 03Michael Chinen 07master:fc736a99eae1: flac_parser.c: fix case when final frame is a false positive [00:53] <kierank> wow flac parser [00:53] <kierank> that takes me back [00:54] <Daemon404> kierank, not in a good way, i assume [00:54] <kierank> i remember a huge ffmpeg bikeshed [00:54] <kierank> of historic proportions [00:55] <Daemon404> i must have been absent for that [00:55] <Daemon404> or mentally blocked it out [00:59] <Compn> i dont remember it but sometimes i ignore epic bikesheds [00:59] <Compn> or webvtt stuff [00:59] <Compn> >400 emails [01:07] <saste> michaelni, do you mind to comment on the bitstream API doxy? [01:07] <saste> and weird enough, it seems I'll have to work even more with that stuff [01:12] <wm4> anyone knows how close the next major release is? [01:13] <michaelni> saste, it would be better if a native english speaker would review it [01:15] <saste> michaelni, you're the one who knows the code better [01:15] <saste> but no hurry, indeed the doxy is not yet complete/correct, with regards with in-place filtering [01:15] <saste> for which I'll need to reverse-engineer the code [01:16] <llogan> saste: s/appliclation/application [01:16] <saste> llogan, irc-review? [01:17] <llogan> i can look at it later tonight if you like if you don't mind my API ignorance. [01:22] <michaelni> saste, ok then ill wait for the next iteration [01:23] <saste> llogan, yes I need both language review and API-wise review [01:23] <saste> they must not necessarily be done by the same person [01:23] <michaelni> ubitux, theres a ping in "WebM muxer writes WebVTT" [01:23] <saste> but my remark still apply, I plan to write a second iteration so no hurry to review it [01:23] <llogan> saste: ok. i'll give you the native american native english speaker review when i get back. [02:18] <BBB-work_> Daemon404, http://arstechnica.com/information-technology/2013/06/c99-acknowledged-at-l… [02:19] <Daemon404> i saw [02:19] <BBB-work_> they mentioned ffmpeg :) [02:19] <Daemon404> been discussing it with wbs and nevcairiel in libav-devel [02:19] <BBB-work_> ah [02:19] <BBB-work_> cool [02:19] <Daemon404> im rewriting makedef and c99wrap as bourne shell this weekend [02:20] <Daemon404> so perhaps we can keep them i nthe source tree [02:20] <BBB-work_> that sounds useful ues [02:20] <BBB-work_> yes [02:30] <kierank> 01:19:55 <"Daemon404> im rewriting makedef and c99wrap as bourne shell this weekend --> explain for the msvc-layman [02:30] <kierank> ? [02:37] <cone-868> ffmpeg.git 03Timothy Gu 07master:a9bbf59be732: cosmetics: Fix "dont" "wont" "doesnt" typos [02:39] <Daemon404> kierank, c99wrap is C, makedef is perl [02:39] <Daemon404> they are part of c99-to-c89 currently [02:39] <Daemon404> but they'd do betetr to be in the src tree [02:39] <Daemon404> as shell scripts [03:36] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:8738d94274ba: avcodec: Make av_register_hwaccel() and avcodec_register() thread safe [03:36] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:08f6fdc3e4bb: avcodec/parser: Make av_register_codec_parser() thread safe [03:53] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:b36b5edb8fea: avcodec/bitstream_filter: make av_register_bitstream_filter() thread safe [03:53] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:53fd1ab26bec: avformat: make av_register_*put_format() thread safe [03:59] <Daemon404> BBB-work_, http://pastebin.com/BtRbWVLb [11:12] <cone-1> ffmpeg.git 03Luca Barbato 07master:afe03092dd69: lavc: move put_bits_left in put_bits.h [11:12] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:c1343897c3c8: Merge commit 'afe03092dd693d025d43e1620283d8d285c92772' [11:38] <cone-1> ffmpeg.git 03Luca Barbato 07master:e30b068ef79f: wmapro: make sure there is room to store the current packet [11:38] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:3e33db3f652e: Merge commit 'e30b068ef79f604ff439418da07f7e2efd01d4ea' [11:48] <cone-1> ffmpeg.git 03Luca Barbato 07master:6652338f43ef: wmapro: return early on unsupported condition [11:48] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:562e8d019ba2: Merge commit '6652338f43ef623045912d7f28b61adea05d27ae' [12:24] <cone-1> ffmpeg.git 03Luca Barbato 07master:38229362529e: wmapro: check num_vec_coeffs against the actual available buffer [12:24] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:a3e9f4c32a92: Merge remote-tracking branch 'qatar/master' [13:04] <ubitux> michaelni: ok gonna review it [13:04] <ubitux> give me a day or two [13:06] <michaelni> ubitux, thanks [13:07] <ubitux> gonna review libgme now [13:18] <ubitux> saste: what's the state of the delogo patches? [13:18] <ubitux> need any review? [13:18] <saste> ubitux, i'll push it the first one [13:18] <saste> the other one needs to be updated [13:19] <ubitux> ok [13:20] <wm4> ubitux: thanks [13:32] <ubitux> ok what can i review now.. [13:37] <wm4> should I attempt to run fate with my libgme patch? [13:38] <ubitux> wm4: it might be relevant for probing [13:39] <wm4> yes I was thinking that [14:15] <cone-1> ffmpeg.git 03Stefano Sabatini 07master:f150db096d9d: doc/muxers: sort muxers by name [14:15] <cone-1> ffmpeg.git 03Stefano Sabatini 07master:d47168e729d6: doc/muxers: apply various minor fixes to segment documentation [15:09] <kwizart> Hello, can we assume neon to be runtime detected on arm nowadays (with current ffmpeg) [15:09] <kwizart> ? [15:21] <BBB> on systems that support it [15:21] <BBB> iirc on android yes, else no [15:21] <BBB> or something like that [15:26] <kwizart> I had linux in mind [15:42] <Compn> then just force detection on it [15:42] <Compn> :P [15:44] <kwizart> I depends on the case, I have both [15:45] <kwizart> it depend on [15:46] <cone-1> ffmpeg.git 03Carl Eugen Hoyos 07master:ac83d621363c: Avoid a null pointer dereference on oom when decoding vc1. [15:47] <kwizart> but I'm building with -mfpu=vfpv3-d16 so neon seems to be miss-detected by ./configure when using this CFLAGS [17:45] <cone-1> ffmpeg.git 03Carl Eugen Hoyos 07master:a1dbe49d02e9: Propagate error return values from the smacker decoder. [17:45] <cone-1> ffmpeg.git 03Carl Eugen Hoyos 07master:90bd75e6eb78: Avoid a null pointer dereference on oom when decoding smacker. [18:09] <xlinkz0> why aren't all the headers in the libs installed? for example ffmpeg.c uses libavutil/colorspace.h but it it not installed [18:11] <Compn> xlinkz0 : its a private header ? [18:11] <Compn> i mean, what else would use it ? [18:11] <xlinkz0> a modified ffmpeg.c :D [18:12] <Compn> pfft [18:12] <xlinkz0> i must make ffmpeg useable from android [18:13] <wm4> yeah, that header is probably private [18:13] <wm4> so why does ffmpeg.c use it? [18:13] <wm4> seems... inconsistent [18:13] <wm4> almost hypocritical [18:14] <Compn> it maybe shared in other parts of the code [18:14] <Compn> like say ffplay [18:14] <Compn> or probably swscale that everyone hates [18:14] <Compn> :P [18:23] <cone-1> ffmpeg.git 03Reuben Martin 07master:2fa89b27365b: Added codec ID to playback DNxHD [18:24] <Compn> oh man [18:24] <Compn> another fourcc/isom [18:25] <Compn> oh gxf [18:25] <Compn> yay [19:02] <Daemon404> [12:13] <+wm4> almost hypocritical [19:02] <Daemon404> almost? [19:02] <Daemon404> no [19:02] <Daemon404> it i. [19:02] <Daemon404> is* [19:03] Action: durandal_1707 those kids today.... [19:09] <durandal_1707> i made pcx to use bytestream2 and libav folk decided that not using bytestream2 is better solution [19:17] <cone-1> ffmpeg.git 03Carl Eugen Hoyos 07master:225f78b7ef58: Avoid a null pointer dereference on clean-up after oom in ac3 encoder. [19:18] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:a2e50fa068dc: Merge remote-tracking branch 'cehoyos/master' [19:37] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:7f866c14ba3d: update all trac links to use the trac subdomain [19:51] <wm4> is there anything definitive whether accessors "must" or "should" be used? [19:51] <wm4> e.g. one place says: [19:51] <wm4> * Code outside libavcodec should access this field using: [19:51] <wm4> * av_codec_{get,set}_pkt_timebase(avctx) [19:52] <wm4> so "should" means -> you don't have to? [19:53] <wm4> it would be a bit troubling because Libav apparently doesn't have these (at least not all of them) [19:55] <michaelni> wm4, if a application wants to link to shared avcodec/avformat and wants to work still when these libs are replaced by newer versions then it needs to use the accessors [19:56] <wm4> what if an application wants to be compatible with Libav [19:56] <michaelni> Libav doesnt have these fields [19:56] <wm4> eh [19:56] <michaelni> Such application can use the more generic AVOption code [19:57] <michaelni> to acces the fields [19:57] <michaelni> which would fail with error code [19:57] <michaelni> if the field isnt available [19:59] <wm4> awesome, more hacks [21:03] <nevcairiel> Daemon404: so afterall still only "almost hypocritical" since it apparently wasn't required :p [21:04] <Daemon404> ;p [21:04] <Daemon404> man [21:04] <nevcairiel> although i'm quite sure the .v files have exceptions for the ff* tools [21:04] <wm4> I think this was needed before the subtitle changes [21:04] <Daemon404> writing bourne shell scripts is hard (tm) [21:04] <nevcairiel> or was that only ffserver anymore? [21:04] <Daemon404> every single post ever about anything [21:04] <Daemon404> is for bash [21:04] <Daemon404> how useless. [21:05] <nevcairiel> how different is the syntax? [21:05] <nevcairiel> or rather, how limited is sh ? [21:05] <nevcairiel> :D [21:05] <Daemon404> well im having a ard time figuring out how to skip the first argument [21:05] <Daemon404> 'shift' is a bashism [21:05] <Daemon404> so is ${var:2} [21:05] <Daemon404> im trying something like ${@:$1} but it leaves whitespace [21:05] <Daemon404> er [21:05] <Daemon404> ${@#$1} [21:06] <Daemon404> hmm.... [21:08] <Daemon404> well i figured it out... but it only works if arguments have no spaces [21:08] <Daemon404> \o/ [21:08] <nevcairiel> are you sure that shift is bash? [21:08] <mark4o> shift is not bash-specific [21:08] <Daemon404> http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html [21:08] <nevcairiel> that doc has shift [21:08] <Daemon404> i can find nothing regarding shift in the POSIX docs [21:08] <nevcairiel> i'm looking at it [21:08] <Daemon404> ctrl-f -> "shift" [21:08] <Daemon404> nothing [21:08] <nevcairiel> http://pubs.opengroup.org/onlinepubs/009695399/idx/sbi.html [21:09] <nevcairiel> you need to follow a link [21:09] <nevcairiel> :D [21:09] <nevcairiel> about "special built-ins" [21:09] <Daemon404> -_- [21:09] <Daemon404> thats annoying [21:17] <Daemon404> ah lovely. mktemp is not POSIX. [21:17] Action: Daemon404 steals configure's [22:38] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:a2802d3cd496: get_pix_fmt_score: favor equal formats if all else equal [22:44] <cone-1> ffmpeg.git 03Derek Buitenhuis 07master:58950ca0df67: ffmpeg: Don't include colorspace.h [00:00] --- Sun Jun 30 2013

1 0

ffmpeg.log.20130629
by burek 30 Jun '13

30 Jun '13

[00:02] <sander455> I have a setopbox and i can get the stream from the web of this box. The stream have a big bandwith and i dont want that. I want to transcode it and restream it. One problem i have when i restream the stream it will lag if i am watching the stream with vlc and look in debug i see alot of warnings like early and timing screwed, stopping resampling. I tried to make a dumpstream with mplayer etc... does anyone know a solution for this. [01:15] <xreal> Are there tools to automatically reach the highest quality for MP4 in multi-pass? [01:20] <llogan> xreal: are you using two-passes becuase you are targeting a specific output file size? [01:21] <xreal> llogan: I used Handbreak up to now, but I want higher quality. [01:21] <llogan> otherwise you can: ffmpeg -i input -codec:v libx264 -qp 0 -preset ultrafast output.mp4 [01:21] <llogan> lossless mode [01:21] <llogan> https://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide [01:22] <xreal> llogan: higher, not highest :) [01:22] <llogan> you said highest [01:23] <xreal> llogan: I am sorry [01:24] <xreal> llogan: in XViD-time, there was auto gordian knot. [01:24] <xreal> Is there something like that for x264 ? [01:24] <llogan> no need to apoligize. i was just giving an example of what you asked for. [01:24] <llogan> read the link i provided [01:24] <llogan> specifically the section on -crf [01:25] <llogan> then read the https://ffmpeg.org/trac/ffmpeg/wiki/AACEncodingGuide if you are also encoding audio [01:26] <xreal> thx# [01:26] <sander455> llogan do you know maybe solution of my problem [01:27] <llogan> sander455: sorry, I don't. [01:28] <sander455> oke [01:33] <brontosaurusrex> xreal, x264 has presest [01:34] <brontosaurusrex> and handbrake is still trying to be smarter than x264 devs [01:35] <brontosaurusrex> and single pas crf encode is considered cool this days [01:35] <brontosaurusrex> pass* [01:36] <xreal> brontosaurusrex: preset like LAME does? [01:36] <brontosaurusrex> yes [01:36] <xreal> oh nice [01:37] <brontosaurusrex> but llogan allready informed you. [01:37] <xreal> yeah, I'll read it tomorrow on train [01:38] <brontosaurusrex> ok and thank me, cos i was the one proposing them in the core in the 1st place [12:22] <xlinkz0> i get this when i try to compile ffmpeg : http://codepad.org/2j0DoArs , i compiled x264 like this : http://codepad.org/udDLis1R [12:23] <xlinkz0> i'm on wheezy [12:23] <JEEB> xlinkz0, if that was the current x264, then it's clearly seeing some unrelated header [12:24] <JEEB> I think X264_VERSION is 133 atm [12:24] <xlinkz0> i've got both latest ffmpeg and x264 [12:24] <xlinkz0> from git [12:24] <JEEB> #define X264_BUILD 133 [12:25] <JEEB> yes, if you had gotten your correct header read [12:25] <JEEB> it would have been 133 [12:25] <JEEB> not 130 [12:25] <xlinkz0> could this be beacuse i had an older version installed but didn't delete it? [12:26] <JEEB> that's a problem if the other installation is in a search directory that is checked before the one you installed to this time [12:26] <xlinkz0> might be [12:27] <xlinkz0> i had an old style instalation [12:27] <xlinkz0> but dunno how to clean up stuff i make installed or the old ffmpeg compile commands installed [12:28] <JEEB> most probably stuff under /usr/local ? [12:28] <JEEB> why do you want to install to the /usr prefix btw? [12:29] <xlinkz0> no particular reason [12:30] <JEEB> because /usr can generally have packages etc. installed there [12:30] <JEEB> while /usr/local in general on linux is left for the user to put stuff into [12:30] <xlinkz0> oh, forgot [12:30] <xlinkz0> what's there other than /usr/include and /usr/local/include? [12:31] <xlinkz0> because i still get those errors after i deleted everything in local/include, lib , bin [12:31] <JEEB> generally libraries go into <prefix>/lib , binaries go into <prefix>/bin and manpages go into <prefix>/shared [12:32] <xlinkz0> and what prefixes are there? [12:32] <JEEB> what you install to? it's not a set-in-stone thing. Anyways, I recommend you make clean first because you're at the linking stage right now [12:32] <JEEB> and it's most probably not going to re-compile any code [12:33] <JEEB> thus you would still get that error since it just tries to link [12:33] <JEEB> and possibly re-configure, too [12:35] <xlinkz0> thanks, it worked :) [12:35] <JEEB> also I really recommend you use /usr/local unless you really know what you're doing [12:35] <JEEB> "Oh geez I happened to overwrite a system library" [12:36] <xlinkz0> understood, is there any way to clean up the stuff i installed to /usr/ ? [12:36] <JEEB> not any automated way [12:36] <JEEB> but if you only installed x264 [12:36] <JEEB> x264.h and libx264 dot-so [12:38] <xlinkz0> thanks [14:31] <LordDoskias> when i'm muxing something with ffmpeg programatically and i do not set the dts value of the AVPacket could this result in no picture or sound being played when i open the muxed file? [14:34] <Mavrik> depends on player and format, but mostly yeah [14:34] <Mavrik> you really can't have a valid mux without dts [14:35] <Mavrik> you probably got a ton of "non-monotonic timestamp" errors which discarded everything you were writing anyway [14:35] <LordDoskias> i only got like 10-15 of those [14:35] <LordDoskias> for the video i only have the pts [15:02] <LordDoskias> Mavrik, wouldn't the av_write_interleaved function automatically workout the DTS values, what if i do not have them ? [15:04] <Mavrik> you can't have video without DTS values, c'mon [15:05] <Mavrik> you MUST know when a frame is displayed [15:05] <Mavrik> otherwise you have random images, not video. [15:07] <LordDoskias> why do yoy need dts and pts [15:07] <LordDoskias> i thought PTS is what is the key value? [15:21] <burek> LordDoskias, because there are cases when you have to decode frame 10 prior to decoding frame 5,6,7,8 and 9 [15:22] <burek> although its not yet time to display frame 10, you need to decode it before 5,6,7,8,9 because they are referencing frame 10 [15:22] <burek> that's why you need both pts and dts [15:22] <burek> pts tells you when to show a frame and dts tells you when to decode it [15:25] <LordDoskias> can't the dts value be inferred? [15:25] <LordDoskias> i get the non monotonic error on several frames e.g. 10-20 out of a 1.20 minutes video [15:26] <burek> inferred from where? [15:27] <LordDoskias> i do not know [15:27] <LordDoskias> but if i have the dts/pts value of an input stream and then i feed it into a hardware encoder (on a raspberrypi) and i get encoded packets do dts/pts change? [15:27] <burek> you can arrange your frames in the container in a random way [15:27] <burek> not neccessarily in PTS order [15:28] <burek> so you need both for the decoder to know when to do what with each frame [15:28] <burek> a hardware encoder (on a raspberrypi) - you really don't wanna go that way [15:29] <LordDoskias> why not? [15:29] <LordDoskias> that's the specs of the project [15:29] <LordDoskias> i want to be able to transcode from mpeg2 to mpeg4 [15:29] <LordDoskias> when feeding data into the decoder i can set a timestamp field which is the PTS value and i get that at the encoder's end [15:29] <burek> you should read more about rpi [15:30] <LordDoskias> well i do have the transcoding working for just video, now i want to put it into a container with appropriate framerate settings etc [15:31] <burek> good luck with that [15:32] <LordDoskias> why? [15:32] <LordDoskias> apparently some other guy already did that [15:33] <burek> then you have nothing to worry about [15:33] <burek> just ignore me :) [15:34] <LordDoskias> well, i;d like to hear your arguments [15:34] <burek> RPi has a very weak cpu [15:34] <burek> and if you wanna use it as an encoder [15:35] <burek> sooner or later you'll realize that you made a mistake choosing that hardware [15:35] <LordDoskias> well, that's the thing - the cpu is weak [15:35] <LordDoskias> the videocore is powerful [15:35] <LordDoskias> it can play full hd with no problems [15:35] <burek> not to mention if you want to do any kind of streaming, since it's all usb based [15:35] <burek> even eth [15:35] <LordDoskias> i'm using the openmax api's [15:35] <burek> you'll just experience some random resets and stuff [15:35] <burek> LordDoskias, playing a HD stream is not a same thing as encoding it [15:36] <LordDoskias> let'me start the encoding [15:36] <LordDoskias> and see what the cpu load is [15:57] <Sevano> HI, I have a problem i want am dumping a stream and want to stream it with ffmpeg when i do this it will be laggy and when i look inside vlc log i see of errors when it will lag. If i unicast and stream i get 0 errors. I think i think streaming will go faster then dumping how i can solve this. [17:44] <bencc> resampling is a separate process before encoding? [17:45] <bencc> or is it a part of the encoding [18:01] <Mavrik> bencc, you can only resample things that are not encoded - so resampling goes after decoding and before encoding :) [18:11] <bencc> Mavrik: makes sense [18:12] <bencc> Mavrik: are there cases where I have to resample? [18:12] <Mavrik> uh [18:12] <Mavrik> well. [18:12] <bencc> for example when transcoding speex to mp3 [18:12] <Mavrik> you have to resample when you want output that uses different sampling rate >P [18:13] <Mavrik> and whether you want output at different sampling rate depends on your wishes and use case. [18:13] <bencc> are there codecs that only support a specific sample rate? [18:13] <brontosaurusrex> some lossy encoders will work better with certain input sample rates, also not all sample-rates are supported everywhere [18:13] <bencc> my use case is to support both Flash (speex) mobile (mp3) and WebRTC users at real time [18:14] <bencc> brontosaurusrex: ok [18:15] <Mavrik> and yes, there are formats that support only limited sample rates [18:15] <Mavrik> as there are players and recorders which also support limited range of sample rates [18:15] <brontosaurusrex> lame used to be best-tweaked for 44.1 some years ago for example, not sure if that is of any validity today. [18:17] <bencc> ok [18:17] <bencc> thanks [18:27] <brontosaurusrex> also some lossy encoders will auto-magically resample the input to whatever they think they need. [18:28] <brontosaurusrex> and some will resample input based on requested bitrate (downsample). [18:28] <bencc> good. I like simple things [18:31] <brontosaurusrex> iam just being "smart" since i have to do the dishes now. [19:51] <mark4o> http://ffmpeg.org/faq.html#Why-does-FFmpeg-not-see-the-subtitles-in-my-VOB-… [19:51] <mark4o> "The size of the initial scan is controlled by two options: probesize (default ~5Â Mo) and analyzeduration (default 5,000,000Â Âµs = 5Â s). For the subtitle stream to be detected, both values must be large enough." [19:52] <mark4o> Looks like the web server is misconfigured. Should be Content-Type: text/html; charset=utf-8 [19:52] <mark4o> It says Content-Type: text/html [19:53] <mark4o> default is ISO-8859-1 [19:53] <mark4o> Also what is Mo? MB? [20:46] <sine``> I have some video footage that says 29fps from a phone. is this exactly 29 frames per second [20:46] <sine``> and how can i dump this into lossless images [20:50] <mark4o> sine``: ffmpeg -i inputfile image%3d.png [20:53] <sine``> thanks [21:18] <sine``> mark4o: [21:19] <sine``> do you know how i can do this but at 50% the origional image size [21:19] <sine``> im doing some video tracking and i want to have a small reference image set for the tracking software, so it will run better [21:21] <mark4o> sine``: you can specify resolution with -s, or use the scale filter: ffmpeg -i inputfile -vf scale=iw/2:ih/2 image%3d.png [21:22] <mark4o> that is 50% in both directions [21:22] <sine``> so vf is video filter [21:22] <mark4o> yes [21:22] <sine``> image width divided by 2 [21:22] <sine``> cool cool [21:23] <sine``> damn ffmpeg is quick [21:24] <sine``> free software is teh best software [21:26] <Nicias> Hello, I have a question about using -vf yadif while transcoding from mpeg2 to x264 mkv [21:27] <Mavrik> yes. [21:27] <Nicias> Here is the command I am using [21:28] <Nicias> ffmpeg -report -v 9 -loglevel 99 -i in.mkv -c copy -vf yadif -c:v libx264 -preset veryfast -crf 20 /tmp/out.mkv [21:28] <Nicias> usually not with the report and loglevel options. [21:28] <Nicias> I recently upgraded from 0.10.7 to 1.0.7. [21:28] <sine``> mark4o: is there a way to apply picture edits to the pictures, such as make bw and increase contrast [21:29] <Nicias> when I was using 0.10.7, I got a line like this in the output [21:29] <Nicias> [yadif @ 0x75fdbb64a0] mode:0 parity:-1 auto_enable:0 [21:29] <Nicias> now with 1.0.7 that has gone. [21:29] <Nicias> no mention of yadif in the output at all. [21:30] <Nicias> it looks to my untrained eye, that it is being deinterlaced, but is the new version just less verbose? Or did it get pickier about where to put the -vf yadif? or something else? [21:32] <mark4o> sine``: sure there are many filters, check the docs http://ffmpeg.org/ffmpeg-filters.html [21:32] <mark4o> sine``: colorchannelmixer has a grayscale example, haven't used that [21:34] <Mavrik> Nicias, no, thats because you're giving conflicting parameters [21:34] <Mavrik> -c copy == -codec copy [21:34] <Mavrik> == copy ALL streams [21:34] <Mavrik> you probably wanted to pass -codec:a copy there right? [21:34] <Nicias> also a subtitle copy. [21:35] <Nicias> so change the -c copy to -c:a copy -c:s copy? [21:35] <Mavrik> mhm [21:35] <Mavrik> it's possible that the way those things are parsed has changed in 1.0 [21:35] <Mavrik> and you're seeing undefined behaviour in action ;) [21:36] <Nicias> that makes sense. I assumed that -c copy -c:v foo would use foo for the video and copy the rest, but It might not be defined. [21:39] <Nicias> ok, so if I change the -c copy to -c:a copy -c:s copy, and then where do I put the -vf yadif? [21:43] <Mavrik> Nicias, after -i should be enough :) [21:43] <Nicias> so something like [21:46] <Nicias> so something like " ffmpeg -i in.mkv -vf yadif -map 0 -c:a copy -c:s copy -c:v libx264 -preset veryfast -crf 20 /tmp/out.mkv " [21:46] <Nicias> hmm. he left. [21:47] <Nicias> I tried that still no mention of yadif in the log. [21:54] <sine``> thanks mark4o [21:55] <Nicias> Since Mavrik seems to have left, can someone else give my question a look? [21:59] <mark4o> Nicias: I don't think that it shows the full list of filters that you've applied in the output [21:59] <Nicias> so it might have just become less verbose? [22:01] <mark4o> I don't remember it ever showing the full list of filters but it might have [22:02] <Nicias> ok. thanks. [22:02] <Nicias> running it both ways now and checking. [22:02] <mark4o> btw 1.0.7 is still old, last stable release was 1.2.1 [22:04] <Nicias> tell that to my distribution :) [22:04] <mark4o> ok :P [22:13] <Nicias> yup, found a more-comby part and it does seem to be doing its job. thanks [22:20] <mark4o> Nicias: yes it looks like yadif used to have its own custom options parsing which included the message you mentioned, but it was changed to use the standard option parsing which allows e.g. yadif=parity=bff instead of having to know magic numbers [22:20] <Nicias> mark4o: that is very helpful. where did you find that information? [22:21] <Nicias> welcome back Mavrik [22:21] <mark4o> Nicias: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7536c671040f1f3ebc9f0d… [22:24] <Nicias> so since it was now using meaningful options instead of magic numbers it no longer reports its parsing of the magic numbers [22:25] <Nicias> I had thought that it was just reporting all the filters it was using and their initializations. I liked that behavior. I guess I will have to trust it that it is doing yadif if I ask it to. [22:26] <mark4o> yes, unlike before, it should now report an error if it is not valid [22:30] <Nicias> thanks for the help Mavrik and mark4o. [23:30] <brontosaurusrex> whats "-c:s copy" ? [23:30] <klaxa> copy the subtitle stream(s) [23:30] <brontosaurusrex> ok [00:00] --- Sun Jun 30 2013

1 0

ffmpeg-devel.log.20130628
by burek 29 Jun '13

29 Jun '13

[01:29] <BBB-work_> j-b, poke! [03:05] <Compn> Daemon404 : i blame you for this http://files.nyaa.eu/HOW_DID_I_PLAYED_BACK.txt [03:08] <Daemon404> its a terrible guide [03:08] <Daemon404> not my doign [03:08] <Daemon404> enjoy. [03:09] <Compn> maybe nevcairiel then [03:33] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:ef9063900430: avfilter/vf_mp: preserve pixel format when possible [04:02] <Compn> hmm were yuvj pix fmts even supported in mplayer filters ? [04:03] <Compn> do ffmpeg filters work with rgb ? [04:09] <durandal11707> nope they only work with mono white [04:10] <drv> but all of my favorite videos are in mono black! [05:14] <highgod> Hi, I want to ask a question, I want to rewrite the av_opencl_register_kernel_code because it has lock operation before thread init if we want to use dynamic lock, so I reference the function avfilter_register, but I found that it does not have any lock either, is it OK, if two threads call the function at the same time, the global variable first_filter may cause some error I think [08:18] <wm4> assume it's possible to demux only one track of a file, is there a way to make this work with libavformat? [08:18] <wm4> since the user can just request any combination of tracks at once [09:52] <michaelni> wm4, if i understand correctly, that would mean the demuxer would have to fail if the user enables more than one track or there would be need for multiple demuxers [09:52] <wm4> michaelni: yes [10:07] <cone-507> ffmpeg.git 03Luca Barbato 07master:6d8629aac136: aac: K&R formatting cosmetics [10:07] <cone-507> ffmpeg.git 03Michael Niedermayer 07master:1bcfb1eea836: Merge commit '6d8629aac13692447b54eac795bf74007ebf8987' [10:08] <wm4> pretty fun how even ffmpeg uses some deprecated ffmpeg functionality [10:14] <cone-507> ffmpeg.git 03Luca Barbato 07master:07c52e2c7c60: aac: return meaningful errors [10:14] <cone-507> ffmpeg.git 03Michael Niedermayer 07master:831e749bc926: Merge remote-tracking branch 'qatar/master' [10:19] <cone-507> ffmpeg.git 03Carl Eugen Hoyos 07master:7f1b3c2ca694: Fix muxing QDM2 mono into caf. [10:19] <cone-507> ffmpeg.git 03Carl Eugen Hoyos 07master:f91833210e74: Set block_align when reading QDM2 in mov. [10:19] <cone-507> ffmpeg.git 03Carl Eugen Hoyos 07master:41f3c60fbb74: Avoid a null pointer dereference in avcodec_decode_video2(). [10:19] <cone-507> ffmpeg.git 03Michael Niedermayer 07master:16310e36d940: Merge remote-tracking branch 'cehoyos/master' [12:48] <cone-507> ffmpeg.git 03Michael Niedermayer 07master:223645671576: avfilter/avfilter: Make avfilter_register() thread safe [13:10] <cone-507> ffmpeg.git 03Timothy Gu 07master:934df3b03757: doc/encoders: alphabetically list the encoders [13:10] <cone-507> ffmpeg.git 03Timothy Gu 07master:7eb5288f17aa: doc/decoders: document libopus decoder [13:55] <superware> I'm struggling with this for days now :| I have an h264-ts-udp stream that doesn't ffplay/ffprobe with "udp://0.0.0.0:1234" but if I dump the stream to a .ts file it plays great. Any ideas?? [13:55] <wm4> superware: debug the protocol implementation? [13:56] <wm4> if there isn't anyone who cares about it, and it has a problem, you're the only one who can fix it [13:58] <wm4> saste: anything about that icy stuff? [14:01] <superware> wm4: but ffplay can play a file with the stream dump, what does it mean? [14:02] <superware> it's like getting the stream off udp doesn't work and getting it from a file does [14:06] <superware> wm4: if I'm getting the stream from UDP by myself, how can I feed it (Transport Stream) to libav* for playback? [14:06] <superware> not playback, for frame extraction.. [14:10] <wm4> superware: you can use custom streams with libavformat [14:10] <wm4> superware: demux_lavf.c in mplayer would be an example for that (although I'm not sure if looking there is a good idea) [14:13] <superware> what would you do? I've used dvbsnoop to inspect the TS and it seems just fine. ffplay can play it from a .ts file, but not from udp. VLC can play it from both. [14:13] <av500> didnt you have some udp error messages? [14:14] <av500> about buffer sizes? [14:15] <superware> using udp://0.0.0.0:1234?buffer_size= or udp://0.0.0.0:1234?fifo_size= didn't help [14:15] <av500> still error messages? [14:15] <superware> yes [14:15] <av500> then you know where to start debugging [14:16] <superware> it seems the data is corrupted [14:16] <superware> when coming from UDP [14:17] <superware> can I stream it to you? :) [14:18] <superware> please? [14:21] <av500> to me? [14:21] <superware> :) please, so you can see the problem [14:23] <av500> sorry, not my day job :) [14:23] <superware> some of the udp datagrams are 18988 bytes long, maybe buffer_size/fifo_size have upper limits? [14:24] <superware> just for a few minutes, helping not working :) [14:26] <superware> av500: ok, that's 101 TS packets in one datagram, maybe ffmpeg can't handle it.. [14:29] <av500> maybe [14:30] <wm4> I doubt ffmpeg cares about datagrams [14:30] <wm4> on the demuxer level [14:31] <superware> but in the udp level libavformat/udp.c, the demuxer level is just fine, it plays nicely from a .ts file [14:35] <superware> does MPEG TS standard forces 7 TS packets per IP packet? [14:36] <av500> no [14:36] <kierank> no [14:36] <kierank> but it makes sense to use 7 [14:37] <kierank> and a lot of devices go crazy if you don't [14:37] <superware> you mean playback devices? [14:38] <kierank> yes [14:38] <kierank> or analysers [14:39] <kierank> ffmpeg probably has an upper limit of packet size [14:39] <superware> or ffplay :) it seems it can't handle 101x188 (18988) at once [14:40] <superware> is it configurable? I can't spot it on https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/udp.c [14:41] <av500> #define UDP_MAX_PKT_SIZE 65536 [14:43] <superware> oh, so I've tried to override this with udp://0.0.0.0:1234?buffer_size=131072&fifo_size=200&pkt_size=64000, but nothing helped [14:48] <superware> av500: the error I see related to udp is "Part of datagram lost due to insufficient buffer size" which is at line 752 [14:49] <kierank> change the max packet size [14:49] <superware> isn't udp://0.0.0.0:1234?buffer_size=131072&fifo_size=200&pkt_size=64000 enough? [14:50] <superware> the largest UDP packets are ~18988 (101x188) bytes [14:53] <superware> kierank: can you please help me? :| [14:53] <kierank> then i don't know [14:53] <kierank> use normal sized packets [14:53] <kierank> :) [14:55] <superware> kierank: it's not under my control. VLC handles it nicely.. [14:56] <superware> the buffer size can be defined, so there's no apparent reason for it not to work other that a bug [14:56] <superware> that=than [14:57] <superware> if you show me where the spec limits packet size, I might be able to do something about it [15:06] <kierank> the spec doesn't limit packet size [15:06] <kierank> it's a convention [15:07] <superware> kierank: so ffmpeg should handle 18988 bytes packets, maybe there's a bug in udp.c? [15:07] <kierank> probably [15:07] <superware> can you please please help me locate it? [15:07] <kierank> fifo_size appears to be a private option [15:08] <kierank> but i don't know much more about the circular buffer thread in udp.c [15:08] <kierank> ask michaelni [15:08] <superware> ok [15:08] <superware> michaelni: hi [15:11] <superware> kierank: what do you mean by "private"? line 555/6 set it [15:11] <kierank> private means it's a demux specific option [15:13] <superware> it's being adjusted in line 588 (*= 188) and used in line 699 in fifo constructor [15:18] <superware> kierank: who else might know? :| [15:31] <superware> kierank: do you happen to know michaelni activity hours? [15:31] <kierank> no [16:03] <BBB> j-b: pokey [16:25] <cone-467> ffmpeg.git 03Carl Eugen Hoyos 07master:2bccd82c29de: Do not list libshine like a main option in configure's output. [17:30] <saste> uhm nobody gonna review my doxy patches? [17:35] <Compn> saste : which ones ? [17:35] Action: Compn afk bbl [17:38] <saste> Compn, i notice that you usually go afk just after doing a question [17:39] <saste> bitstream API and AVPicture API [17:58] <Compn> saste : its fun , but rain has spoiled my afk plans [18:59] <Daemon404> wm4, nicolas is a perfect example of the inbreeding / bubble-life of ffmpeg [19:00] <wm4> Daemon404: but even reimar disagrees with him [19:00] <Daemon404> so far its 3-to-1... we shall seee how it goes [19:00] <Daemon404> my money is on stubborness [19:01] <Compn> ghost in the shell arise is terrible. character redesign, fanservice, no yoko kanno [19:01] <wm4> honestly I'm starting to stop caring... I use it for a few obscure cases only, anyway [19:01] <wm4> and it's not that important [19:01] <Daemon404> it == ffmpeg? [19:01] <wm4> no the issue at hand [19:01] <Daemon404> heh [19:02] <Daemon404> mixed encodings in subtitles filers is *ver* common [19:02] <Daemon404> very* [19:02] Action: Daemon404 shrugs [19:02] <wm4> as for ffmpeg... I guess I can't not use it [19:02] <Daemon404> the eternal struggle [19:02] <Daemon404> "what is this stupid shit?" [19:02] <Daemon404> "i have no choice.. meh" [19:02] <wm4> yeah, but this affects only the libavcodec subtitle converter [19:02] <Daemon404> well nobody uses that [19:03] <Daemon404> for a reason [19:03] <wm4> the only "important" cases I use it for are smi and webvtt [19:03] <wm4> (btw. the smi reader doesn't really work on real world files) [19:03] <Daemon404> smi are pretty common too [19:03] <Daemon404> (in china) [19:04] <wm4> and korea [19:04] <Daemon404> wm4, i dream of one day when libaegisub is usable as a library [19:04] <Daemon404> but that day prbably wont come. [19:04] <wm4> a generally usable subtitle library sure would be nice [19:06] <Daemon404> oh well [19:06] <Daemon404> time for crepes [19:06] Action: Daemon404 vanish [19:07] <Compn> wm4 : ati cards support vdpau ? [19:07] <Compn> wm4 / Daemon404 : btw just start attaching your smi files as samples , thats how this project works. samples or ignore bug report [19:10] <wm4> Compn: I reported it to ubitux (who wrote this), but he lost interest [19:10] <wm4> such is the way of open source [19:31] <iive> Compn: radeon+mesa3d add vdpau decoding. should be avaliable in 3.10 kernels and mesa 9.2 [19:32] <wm4> libva has a xvba backend too [19:32] <wm4> though I heard that it's unmaintained and bad [19:43] <wm4> wow testing .rm in low memory situations [19:43] <JEEBsv> :D [19:43] <wm4> seriously the sttff this guy finds [19:43] <wm4> *stuff [21:03] <superware> michaelni: hi [21:29] <michaelni> superware, hi [21:31] <superware> how are you? saw my email to you? :) [21:38] <superware> michaelni? [21:40] <michaelni> superware, my inbox is full of mails i was afk a bit :) [21:41] <superware> can I please describe you the issue? [21:42] <ubitux> superware: why don't you just open a bug report? [21:42] <superware> well it might be hard to reproduce [21:45] <superware> I have a device unicasting a h264-ts-udp stream which ffmpeg/ffplay/ffprobe have troubles playing. When I dump the udp dump to a .ts file it plays nicely. The main issue seems to be "Part of datagram lost due to insufficient buffer size", after some investigation it turns out that stream contains 18988 bytes long datagrams (101*188 TS packets) which udp.c/fifo.c has troubles with. Using [21:45] <superware> udp://0.0.0.0:1234?fifo_size=200 didn't help. [21:47] <michaelni> superware, which buffer/fifo exactly is causing the problem ? [21:48] <superware> I guess https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/udp.c#L752 [21:49] <superware> I'm not really 100% sure this is the problem, but a) the TS stream is playing when dumped to a file, b) that stream contains quite big datagrams. [21:52] <michaelni> is there a easy way to reproduce this ? [21:52] <superware> I can send the stream to any IP you'll give me [21:52] <superware> (will it work over the internet?) [21:53] <superware> very small, about 200kbps [21:53] <michaelni> id prefer a local way to reproduce it if possible [21:54] <michaelni> more predictable/reproduceable and i dont have to mess with the router to forward it [21:54] <superware> then I guess somehow produce a stream with 101*188 bytes datagrams [21:55] <superware> I rather think me send the stream to you (for as long as we need) might be a faster method to find the bug/issue [21:55] <superware> send=sending [21:56] <superware> I'll really appreciate it [21:56] <michaelni> what are you using to send the stream ? [21:57] <superware> what do you mean? it's an encoder card [21:57] <michaelni> hmm ok [21:59] <michaelni> being able to locally reproduce this would also come in handy for regression testing later btw [21:59] <superware> we can think about this after we solve the problem :) [21:59] <michaelni> that is we could check future changes against it to make sure we wont break it again once its fixed [22:00] <superware> of course [22:00] <superware> I can prepare a small utility that will send a TS file using large datagrams [22:01] <michaelni> that would be very usefull [22:01] <michaelni> if its reproduceable with it [22:01] <superware> but it might take me time, can we still try me sending the stream to you in the meantime? [22:01] <superware> that's another question [22:02] <superware> can I please /msg you? [22:03] <michaelni> can i see the full uncut output with all warnings and debug stuff that you get when this bug happens ? [22:03] <superware> yes, a sec [22:08] <superware> http://pastebin.com/iAAP3isS [22:18] <superware> michaelni: do you need more info? [22:27] <michaelni> superware, dunno, maybe a backtrace from where the error gets printed but i think i can guess where that will be [22:32] <superware> backtrace? how? [22:33] <llogan> http://ffmpeg.org/bugreports.html [22:34] <Daemon404> wm4, i think i may refrain from being involved anymore in ths [22:34] <Daemon404> it just rots my brain [22:34] <wm4> heh [22:34] <wm4> he'll probably create a monster [22:34] <superware> llogan: but there's no crash [22:35] <Daemon404> wm4, and i will continue to not use ffmpeg's subttle facilities [22:35] <Daemon404> because of shit like this. [22:35] <durandal11707> shit being ... ? [22:36] <wm4> well, the subtitle demuxers are probably slightly better than MPlayer's hilarious old code, so I'll use it [22:36] <Daemon404> read any of nicolas' replies to wm4's patch, durandal11707 [22:36] <Daemon404> that shit. [22:37] <Daemon404> he lives in an imaginary world [22:37] <durandal11707> that little patch ... [22:37] <wm4> yeah, way too much effort for such a small patch [22:37] <wm4> so I guess I'll stop caring [22:37] <Daemon404> i gotta say, he does a great job of the neckbeard-style "all output is correct or it wont work" [22:37] <Daemon404> completely unrealistic. [22:39] <durandal11707> use AV_EF_AGGRESSIVE ? [22:39] <nevcairiel> isnt there a explode flag for giving up on errors [22:40] <Daemon404> nevcairiel, doenst matter. he argues it's not "correct" to ever return anything thats not perfect utf8 [22:40] <durandal11707> you always could add new AV_EF_.... [22:41] <Daemon404> durandal11707, unfortunately i think this is an ideaological issue nicolas has [22:41] <Daemon404> i dont think anything else will pelase him [22:41] Action: Daemon404 shrugs [22:42] <wm4> yeah, he's rejecting even a flag to disable the check [22:43] <superware> michaelni: I've just checked with a friend, he managed to receive the stream over the net [22:43] <Daemon404> wm4, dreppers gonna drepper [22:43] <Daemon404> that is all. [22:44] <wm4> now I feel sorry for dreppering on another place today [22:44] Action: durandal11707 will stop this [22:45] <Daemon404> wm4, let me just not merge some gl3 code because i have to rewrite all the man pages first [22:45] Action: Daemon404 runs [22:45] <Daemon404> (unrelated, but \FOSS/ [22:45] <wm4> oh yeah that's kind of what happened [22:45] <Daemon404> i know. [22:46] <wm4> so I forked an already weak project forked from another weak project, I guess that's FOSS too [22:47] Action: nevcairiel created something new [22:47] <Daemon404> thats different [22:47] <Daemon404> ffdshow was not saveable [22:47] <Daemon404> by any means. [22:48] <nevcairiel> exactly [22:48] <nevcairiel> the code still gives me headaches when i look at it [22:48] <Daemon404> /* ffdshow custom code */ [22:48] <nevcairiel> thats just because they are too stupid to use a vcs to manage their patches [22:49] <wm4> that code must ridden with years of hacks that deal with dshow interaction with other software [22:49] <wm4> I can imagine that this part is the least fun [22:49] <nevcairiel> that reminds me that i need to clean up my patches again and submit the clean ones [22:50] <wm4> nevcairiel: do you intend to merge that haali thing with ffmpeg mainline? [22:50] <nevcairiel> no [22:50] <wm4> too windows specific? [22:51] <nevcairiel> not really [22:52] <Daemon404> there's no reason really [22:52] <nevcairiel> i just don't think it belongs in upstream, its an ugly hack to work around the shortcomings of the native mkv demuxer [22:53] <Daemon404> ffms2 has the exact same thing [22:53] <wm4> couldn't it replace the native demuxer? [22:53] <Daemon404> i wouldnt be surprised if nevcairiel ripped it from there [22:53] <nevcairiel> nah [22:53] <nevcairiel> i just used haalis demuxer and made a thin avformat wrapper at first [22:53] <nevcairiel> then it grew [22:54] <nevcairiel> now its full of weird special logic for ordered chapters/segment linking [22:54] <Daemon404> ffms2 is 'cleaner' but uglir too [22:54] <Daemon404> cause it uses haali completely separately [22:54] <Daemon404> and then decodes with lbavcodec [22:54] <Daemon404> excpt lavf doesnt export its matroska mappings [22:54] <Daemon404> thus, lavc is unusable with it without copying it [22:55] <nevcairiel> yeah i didnt want to implement a separate demuxer backend into my own code, so i put it into lavf [22:56] <Plorkyeran> probably a better solution since lavf and lavc are pretty clearly not designed to be used separately [22:56] <wm4> oh what heretic words [22:56] <nevcairiel> well, i always use them separately, and it usually works fine [22:56] <superware> michaelni: do you want me to redirect the stream? [22:58] <durandal11707> wm4: concealment for subtitles is none but there should be one.. [22:58] <michaelni> superware, no, i succeeded reproducing a similar possibly identical issue already [22:58] <durandal11707> wm4: there should be option to not do concaealment and instead abort immediatelly [22:59] <superware> michaelni: wow, great! [22:59] <wm4> durandal11707: well, Nicolas seems to have his own plans... from what I've read, he'll probably implement sub codepage autodetection and some error concealment stuff [23:00] <durandal11707> in near or distant future? [23:00] <wm4> who knows [23:02] <durandal11707> spam him, or do it yourself, it doesn't appear to be lot of work [23:09] <durandal11707> why is not possible to flag packets as keyframes from parser? [23:09] <nevcairiel> that is possible [23:10] <nevcairiel> you need to set "key_frame" in the parser context, and the code in utils.c will then copy it into the packet [23:10] <nevcairiel> rather ugly because parsers dont take AVPackets [23:10] <nevcairiel> but hey [23:11] <nevcairiel> see parse_packet in lavf/utils.c [23:12] <durandal11707> is that actually used by any parser? [23:13] <nevcairiel> h264_parser uses it [23:14] <nevcairiel> seems to be the only one, though [23:19] <superware> michaelni: have you found the bug? :) [23:20] <michaelni> superware, iam working on several things, not just that bug ... [23:25] <superware> sure, thanks [23:25] <superware> just curious you know [23:32] <cone-868> ffmpeg.git 03Paul B Mahol 07master:36748d4b6ca9: tak_parser: properly mark packets as key frames [23:34] <michaelni> btw, about subtitles, if someone designs a better system and is willing to maintain it and asks me to merge/pull i wont hesitate to merge it after checking that it is better [23:40] <durandal11707> "If it only kills one out of every 100 crews, as an example, their made be no need to bother with additional expensive shielding." [23:43] <wm4> durandal11707: why is key frame info important? [23:45] <durandal11707> taking single packet, which does not have required info, you can not succesfuly decode it in one go (instead you need to play rulette) [00:00] --- Sat Jun 29 2013

1 0

ffmpeg.log.20130628
by burek 29 Jun '13

29 Jun '13

[00:44] <mcepl> I have a DVD dump (looks like MPEG-2) which has subtitles included inside ... I would like to convert (especially compress) the file to .MP4, but I would like still to preserve those internal subtitles. ffmpeg -i file.mpg file.mp4 doesn't seem to be the trick. ANy thoughts? [00:45] <sacarasc> The subtitles are most likely vobsubs. I am not sure they can go into MP4. If they can't, you'd have to convert them using some kind of OCR. [00:45] <mcepl> what are vobsubs? some kind of graphic? [00:46] <sacarasc> Yeah, they're bitmaps. [00:47] <mcepl> how could I find out? ffplay -stats -vn -an file.mpg doesn't seem to mention them. [00:49] <adnap> Wow, so that was what vobsubs were. So ghetto [00:49] <Frantic1> Hey guys, I'm trying to process a video with ffmpeg 1.2.1, and I've stumbled across a weird video. Every player can play it (QuickTime, VLC, Chrome player). http://i.imgur.com/IJAGkzO.png [00:49] <Frantic1> But, the video is at 1920width [00:50] <Frantic1> Though, ffprobe and inspect report it at 1440w [00:50] <Frantic1> Quicktime's inspect, however, gives the thing you see in the image, two resolutions for the same thing [00:50] <Frantic1> Could someone please tell me what's going on with this file? :) [00:51] <Frantic1> btw, output from ffprobe is here: https://gist.github.com/anonymous/f66ce998b8b6855380d1 [00:53] <vulture> maybe one is some resolution from the container, or a resolution format table lookup id (mpeg does this and it's worthless), and then the other is the actual resolution used? [00:53] <sacarasc> Frantic1: Some files have different display ratios and storage ratios. This is quite common on TV channels. [00:54] <Frantic1> if I reencode it, it works OK, but I'm also trying to get a poster image for it with -f image2, and that gives me an image at the wrong aspect ratio [00:55] <Frantic1> sacarasc: I think you are right, In lines 15-16 of the gist, there's "sample_aspect_ratio" and "display_aspect_ratio", those are different [01:01] <Frantic1> yep, that's it :) [01:02] <Frantic1> Basically every player does in fact play the video correctly [01:02] <Frantic1> so apparently it's something common as you say [01:02] <Frantic1> But, does anyone know how I might be able to get a frame from it at the display aspect ratio? [01:03] <sacarasc> Use -aspect 16:9 or something, I guess. [01:03] <Frantic1> I'm just reading through `man ffmpeg`, but setting -aspect doesn't help :( [01:03] <Frantic1> yep, it's the only thing i found as well [01:04] <Frantic1> I'm trying: ffmpeg -i /Users/tudor/proj/phoenix/media/uploads/19._individual_approach_in_LNP_.mp4 -ss 10 -f image2 -frames:v 1 -aspect "16:9" -y x.jpg [01:04] <Frantic1> still prduces 4:3 image [01:07] <tsjiller> Frantic1: tried -vf "scae=1920:1080" ? [01:08] <tsjiller> s/scae/scale [01:08] <Frantic1> tsjiller: if I just do -s 1920x1080, it works [01:08] <Frantic1> tsjiller: but I'm looking for a generic solution [01:09] <Frantic1> because I have no idea what aspect or size the next video will have [01:09] <Frantic1> currently I'm thinking of getting 4/3 16/9 and scaling the image by that [01:10] <Frantic1> but I'm just hoping that ffmpeg has a way of outputting the image at the display ratio, so I don't have to do this extra step which can lead to a 1px off due to float rounding [01:13] <tsjiller> you can use logic functions in the scale stuff. [01:13] <tsjiller> http://ffmpeg.org/pipermail/ffmpeg-user/2011-July/001746.html has some info [01:14] <tsjiller> if I understood you correctly [01:16] <Frantic1> tsjiller: that's cool, but it just scales any video to 16:9, I don't want to always scale to 16:9, I want to always scale to the display ratio [01:17] <Frantic1> and the display ratio can be whatever the video says it is [01:18] <Frantic1> am I the first person to try to get poster images for videos with ffmpeg? :) [01:22] <mark4o> Frantic1: -vf "scale=iw*sar:ih" [01:23] <Frantic1> mark4o: that worked! [01:23] <Frantic1> thank you [01:23] <Frantic1> though, will that still work when sar and dar are the same? [01:24] <mark4o> yes [01:24] <Frantic1> yes, it does :) [01:25] <Frantic1> I don't understand why, though [01:25] <mark4o> why would sar and dar be the same? unless you have a square image [01:25] <Frantic1> aren't they usually the same? [01:26] <mark4o> no, if it is a computer image then sar is 1:1 and dar is the width/height, which is usually not square [01:26] <Frantic1> I may be wrong, I'm not sure what SAR is, I guess it's the ratio at which the video was when it was sampled [01:26] <mark4o> sar is the aspect ratio of each pixel [01:26] <mark4o> which on a computer monitor is 1:1 [01:27] <Frantic1> oh [01:27] <Frantic1> I'll read some more on the topic then, I seem to have assumed wrongly what that was [01:27] <Frantic1> thanks a lot for your help guys [01:28] <Frantic1> I was actually writing the code to manually get the difference between sar and dar and apply it to w :) [01:34] <Frantic1> mark4o: I got it now, thanks a lot for your patience [01:34] <mark4o> np [01:44] <Frantic1> I have one more issue that maybe you guys can help me understand [01:44] <Frantic1> I'm rendering a player with my processed video. I have a fixed width, and I am varying height in order to keep the aspect ratio and not have black bars [01:45] <Frantic1> I used to always get streams[video_sream_id][width] / height, and use that ratio, but now that I know about the SAR, I have to factor that in as well [01:45] <Frantic1> but I have a video, which has DAR and SAR showing "0:1" [01:46] <Frantic1> does that mean somthing? Or is the video bad? [01:46] <Frantic1> I'm just probing random videos to see if I run into problems [02:00] <mark4o> Frantic1: if it is 0 then it is unspecified; you'll need to guess, or assume sar=1:1 and dar=width/height [02:57] <RigidWig> how can I feed ffmpeg a list of images in a sequence of my choosing? [03:04] <grepper> RigidWig: one way would be to symlink to %03d.png or whatever (001.png 002.png etc) then use that. [03:05] <grepper> ffmpeg -f image2 ... -i %03d.png ... [03:12] <mark4o> RigidWig: or -f image2 -pattern_type glob -i "{first,second,third}.png" might work [03:29] <Mista_D> http://pastebin.ca/2410257 having problems with buring in time stamps to a 24p video... [03:31] <Mista_D> got it... its a :/;/. in timestamp format. [04:08] <llogan> RigidWig: also see -start_number option: http://ffmpeg.org/faq.html#How-do-I-encode-single-pictures-into-movies_003f [04:08] <llogan> https://ffmpeg.org/trac/ffmpeg/wiki/Create%20a%20video%20slideshow%20from%2… [04:09] <llogan> Mista_D: my brother had "Mista C" on his hard hat until his co workers started calling him "Mistake". [05:28] <blink> /cls [09:37] <diroots> hi there! [09:57] <diroots> I have an issue with ffmpeg when encoding DVCPRO HD to H264. DVCPRO HD are files with size set to 1440x1080i [PAR 4:3 DAR 16:9], but displaying as fullHD (1920x1080) (and mediainfo reports "2" sizes : width : 1440 original width 1888 height 1062 original height 1080, i think it's these info which permit to view DVCPROHD files either in 4:3 or 16:9), and when I encode it to H264, i get videos with size 1440x1080 (so their aspect ratio is 4:3 only). do I ne [09:57] <diroots> ed to explicitely force -s 1920x1080 during encoding? or -video_size hd1080 ? or force aspect ratio? [10:16] <mrAlmond> Hi everyone [10:17] <mrAlmond> I've encoded a video using Android H264 encoder then I've muxed it with ffmpeg in c code. [10:17] <mrAlmond> it's an mp4 container [10:18] <mrAlmond> It works well in VLC but it gaves me error on Windows Media Player [10:18] <mrAlmond> this is the MP4Box output [10:18] <mrAlmond> http://pastebin.com/meP2Dfw8 [10:19] <mrAlmond> there is no audio track, only video [10:19] <mrAlmond> h264 avc base profile [10:20] <diroots> mrAlmond: did you try with an audio track? same result? [10:21] <mrAlmond> this is the ffprobe [10:21] <mrAlmond> http://pastebin.com/DifENUMX [10:22] <mrAlmond> diroots : No, at the moment I haven't tried with audio track as I'm recording video from a camera that has no audio input [10:24] <diroots> try adding an audio track to your file, to see if WMP still complains [10:24] <mrAlmond> do you have a ffmpeg command line to add a dummy audio track to it? [10:25] <diroots> https://www.google.com/search?q=ffmpeg+adding+audio+ [10:26] <mrAlmond> I was just searching now in google [11:28] <mrAlmond> diroots : I've tried to add a silent audio track but windows media player sees it as an audio only file [11:28] <mrAlmond> I've also tried to install K-lite codec pack and now it works! [11:28] <mrAlmond> Does this mean that the codec I'm using is not supported by windows? [11:30] <zap0> probably. [11:37] <mrAlmond> it's avc base profile [11:37] <mrAlmond> is h264 base profile not supported by WMP? [11:41] <JEEB> mrAlmond, it is with Win7+ [11:42] <JEEB> are you sure you muxed with AVCc [11:42] <JEEB> and not Annex B or something crappy otherwise [11:43] <JEEB> as in, did you follow 14496-15 [11:43] <JEEB> libavformat will not do this automatically for you [11:47] <mrAlmond> we muxed in avcc [11:48] <JEEB> ok, then it should work with Win7 and newer [11:48] <mrAlmond> we filled extradata and converted annexb format to avcc [11:48] <JEEB> I think Vista has the decoders included as an update package [11:48] <JEEB> but I have no idea how well they work in WMP [11:49] <mrAlmond> do you see something strange inthe ffprobe? http://pastebin.com/DifENUMX [11:51] <mrAlmond> it's a variable framerate video [11:51] <mrAlmond> here it says 18.74 fps but I think it's an average [11:51] <JEEB> you shouldn't be bothered by that too much [11:52] <mrAlmond> also quicktime doesn't work [11:52] <mrAlmond> it just shows a black screen [11:52] <JEEB> lol [11:52] <mrAlmond> in linux mplayer and vlc work [11:52] <JEEB> sounds like you have failed [11:52] <JEEB> yes, naturally crap that uses libav* will work [11:52] <JEEB> does flash player work? [11:53] <mrAlmond> gstreamer does not work [11:53] <JEEB> anyways, I have no idea at what point, but you have successfully created a broken file in some way it seems :P [11:53] <JEEB> tried demuxing the AVC stream into annex b with ffmpeg or something [11:53] <JEEB> and then remuxing it with L-SMASH's muxer? [11:54] <JEEB> http://code.google.com/p/l-smash/ [11:54] <JEEB> also the boxdumper application from L-SMASH will most probably be of use [11:54] <mrAlmond> we are using android mediacodec classes to encode that video [11:54] <mrAlmond> and then ffmpeg to mux it [11:54] <mrAlmond> Android is able to play it [11:55] <JEEB> yes, and I'm telling you to demux the AVC stream as Annex B again [11:55] <JEEB> and remuxing with L-SMASH's muxer [11:55] <JEEB> then see if the results change with anything [11:55] <mrAlmond> ok [11:55] <mrAlmond> thank you for the suggestion [11:56] <JEEB> also as I said, boxdumper is a great tool for checking how the "mp4" file is constructed [11:58] <mrAlmond> great, I will try it [12:18] <mrAlmond> JEEB : if we are missing stss atom could it be the problem? [12:22] <muken> mrAlmond: absence of stss atom means all frame is a random access point [12:27] <mrAlmond> Paranoialmaniac so is it normal that without stss it doesn't play in windows media player? [12:27] <mrAlmond> but it plays in vlc [12:28] <Paranoialmaniac> wut [12:28] <Paranoialmaniac> does wmp load an appropriate splitter? [12:29] <mrAlmond> wut? :-) [12:29] <mrAlmond> I don't know [12:35] <JEEB> wmp, unless you have poked around should use the MS things by default [12:36] <JEEB> also how did the demux + remux go? [13:49] <superware> I'm struggling with this for days now :| I have an h264-ts-udp stream that doesn't play with "udp://0.0.0.0:1234" but if I dump the stream to a .ts file it plays great. Any ideas?? [13:49] <superware> (I'm using ffplay/ffprobe) [13:54] <arpu> hello @all [13:54] <arpu> is it possible to reencode and send to rtmp server of files in a directory without restart ffmpeg on new files? [16:35] <sine``> is there an alternative to using batch files on windwos to use ffmpeg [16:36] <sine``> like an updated gui front end [17:28] <zap0> sine``, WinFF [17:31] <sine``> but thats old [17:31] <sine``> is there regular updates [17:41] <zap0> its a GUI. what's the problem? have the icons faded? [18:13] <sine``> no i mean the command line parameters have changed over time [18:15] <zap0> you can make your own presets, pass your own cmd line params [19:22] <Maverick|MSG> are there any image quality comparisions available between the different preset values [19:22] <Maverick|MSG> like medium vs slow [19:22] <Maverick|MSG> slow's filesize is obviously smaller, but does that result in a lower/higher quality video? [19:26] <llogan> Maverick|MSG: http://pastebin.com/JSrXhWYf [19:33] <Maverick|MSG> oo, thanks again llogan [19:45] <Maverick|MSG> for the record, it looks like moving from medium to slow will decrease the output filesize by about 1.25% [19:46] <Maverick|MSG> (at least based on what I'm encoding) [21:15] <superware> michaelni: hi [22:05] <mibofra> hi guys :) [22:05] <mibofra> excuse me for the off topic but I don't know where I can find info about it [22:06] <mibofra> Does anyone know a irc channel for AAlib? [22:06] <llogan> mibofra: maybe there was one in 2001. [22:07] <llogan> you could use libcaca instead [22:08] <mibofra> thanks [22:08] <brontosaurusrex> the ascii library? [22:08] <llogan> mibofra: then you could go to #libcaca [22:09] <mibofra> brontosaurusrex, yep [22:09] <mibofra> llogan, ok [22:09] <mibofra> thanks guys [22:42] <Maverick|MSG> is there a way to ise itsoffset but only have one input (-i) defined? [22:42] <Maverick|MSG> *use [22:43] <Maverick|MSG> rather than: -i input.avi -itsoffset 5 -i input.avi ... [22:43] <Maverick|MSG> something like: -itsoffset 5 -i input.avi -map 0:0 -map -0:1 [22:48] <Maverick|MSG> the audio in my input is delayed 5 seconds, so I need to move it forward a bit so things are sync'd [23:38] <mark4o> Maverick|MSG: ffmpeg -i input.avi -af "asetpts=PTS-5/TB" ... [23:39] <Maverick|MSG> hm, not familiar with those settings [23:39] <mark4o> asetpts sets audio timestamps to timestamp minus 5 seconds [23:40] <Maverick|MSG> what does /TB mean? [23:40] <llogan> Maverick|MSG: http://ffmpeg.org/ffmpeg-filters.html#setpts_002c-asetpts [23:40] <Maverick|MSG> ah, thanks llogan, was just looking for thart [23:40] <mark4o> timebase [23:40] <Maverick|MSG> cool, let me read up a bit [23:40] <Maverick|MSG> thanks guys [23:46] <Maverick|MSG> mark4o llogan thanks a ton. it worked! [23:50] <Maverick|MSG> is there an advantage to using that as compared to the itsoffset? [23:51] <llogan> you can use it in a filtergraph. you can apply it to specific streams more sanely. [23:51] <sander455> Hi [23:51] <Maverick|MSG> yeah, minus the syntax it seems a little bit easier to manage [23:51] <mark4o> or to just audio or just video -- -itsoffset applies to all streams [23:51] <llogan> the syntax just takes some getting used to [23:52] <mark4o> because it is more flexible [23:53] <mark4o> although -itsoffset:a would be nice [00:00] --- Sat Jun 29 2013

1 0

ffmpeg-devel.log.20130627
by burek 28 Jun '13

28 Jun '13

[00:08] <saste> $ffplay ffplay [00:10] <Daemon404> wut [00:21] <saste> ^^ ffplay plays with itself [00:24] <llogan> ffapper [00:26] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:205092bf478f: ffprobe: simplify branching logic in probe_file() [00:26] <cone-855> ffmpeg.git 03Nicolas George 07master:a334b00cf62c: ffprobe: fix exit code with stream specifiers [00:26] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:1fc626f8d072: ffprobe: reindent after previous commit [00:27] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:5c616fe48bf6: ffprobe: always exit 1 in case of errors [00:44] <troker> Hey all, looking for an older copy of ffmpeg (version .60 to be exact) for some research. Anyone know where I might be able to find it? [00:45] <Compn> yes [00:45] <Compn> should be in release dir [00:45] <Daemon404> http://ffmpeg.org/download.html [00:45] <Compn> troker : http://ffmpeg.org/releases/ [00:46] <Daemon404> Compn, please do not encourage people to download older stable releases [00:46] <troker> thanks! [00:46] <Daemon404> 0.6.6 is compatible with 0.6.0 [00:46] <Daemon404> its the whole point of stable branches. [00:49] <Compn> bwahaha [00:49] <troker> Daemon404: Well Im looking for a build with this particular vuln http://www.securityfocus.com/archive/1/archive/1/514009/100/0/threaded -- would that be in 6.1? [00:49] <troker> (again research, I know vulnerable code is vulnerable) [00:50] <Daemon404> man thats super old [00:50] <Daemon404> before multithreading was even merged [00:50] <Compn> 2010 [00:50] <Daemon404> the commit hash doesnt even exist [00:51] <troker> Is the code gone? or is it findable [00:51] <Daemon404> also [00:51] <Daemon404> libavcodec <= 0.6 [00:51] <Compn> Daemon404 : see mr smarty pants, if he chose your .6.6 version, its probably the one with the vuln fix [00:51] <Daemon404> is confusing [00:51] <Daemon404> because libavcodec version != ffmpeg version [00:51] <Compn> it means ffmpeg [00:51] <Compn> in this case [00:51] <Daemon404> yeah... [00:51] <Compn> but yes confusing to me :D [00:52] <troker> Yea I know its old, Im using it to test the methods here http://user.informatik.uni-goettingen.de/~krieck/docs/2011-woot.pdf [00:52] <Daemon404> http://gitorious.org/~net1945/ffmpeg/net1945s-ffmpeg-mt/commit/16c592155f11… [00:52] <Daemon404> just check out the hash before this one [00:52] <Compn> troker : try the 0.6.0 , not the 0.6.6 as it could possibly include a fix for that vuln [00:52] <Compn> :P [00:52] <Daemon404> or just use the exact hash given in teh cve [00:52] <Daemon404> and save the hunting trouble [00:54] <troker> Compn: I see no 0.6.0, do you mean 0.6.release? Or would that be patched [00:54] <Daemon404> [18:52] <@Daemon404> http://gitorious.org/~net1945/ffmpeg/net1945s-ffmpeg-mt/commit/16c592155f11… [00:54] <Daemon404> [18:52] <@Daemon404> just check out the hash before this one [00:54] <Daemon404> READ [00:54] <Daemon404> this is the exact hash given in the cve [00:54] <Daemon404> which fixes the fuc [00:54] <Daemon404> er, bug [00:54] <Daemon404> ergo, checkout the revision before it [00:54] <Compn> yeah what Daemon404 says is better [00:55] <Compn> http://ffmpeg.org/releases/ffmpeg-0.6.tar.gz is the .6 one . i dont know if its patched. but the tarball is 6-2010 and the vuln was fixed in 9-2010 so it seems to be right ... [00:55] <Daemon404> goddammit Compn [00:55] <Compn> bwahaha [00:55] <Daemon404> stop leading people down shit paths [00:56] <Compn> hes the one trying to root someones box using a malformed file [00:56] <Compn> and you're helping him [00:56] <Daemon404> if he was trying to root someone's box, he'd already know the exact version [00:56] <Daemon404> also people running vuln cod from 2010 have it coming. [00:56] <Compn> i didnt say he was good at it [00:56] <Compn> :P [00:56] <troker> Yea all us security guys are evil. [00:57] <Compn> yes, you are [00:57] <Compn> making ffmpeg, a video encoding project, fix vulns for hours on end when that time could be better spent adding more codecs and features :P [00:57] <saste> diary of a bug hunter also contains a few nice exploits of ffmpeg vulnerabilities [00:57] Action: Compn bitter [00:58] <troker> That paper I linked up there ^ will *hopefully* cut down time spent doing just that [00:58] Action: Compn also kidding [00:59] <troker> I agree though! Bug hunting takes far too long! Lets optimize! [00:59] <troker> With Science! [00:59] <troker> (") [00:59] <Compn> what, no cake ? [00:59] <troker> That happens after you find the bug [02:10] <cone-855> ffmpeg.git 03Marton Balint 07master:9fac752afa96: ffplay: simplify and fix flushing out old subtitles on seeking [02:10] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:e4198d2fc3d9: Merge remote-tracking branch 'cus/stable' [06:16] <anshul> i was trying to solve ticket "https://ffmpeg.org/trac/ffmpeg/ticket/2716" , have more than one solution,plz help [09:16] <saste> michaelni, any reason why we don't store the timebase in AVFrame? [10:05] <michaelni> saste, probably no reason [10:45] <anshul__> is there any spevific format. to send an patch, i feel mine patch is ignored on ffmpeg-devl mailing list [10:46] <av500> git format-patch [10:47] <nevcairiel> you posted your patch 2 hours ago, so .. seriously? complaining already? [10:47] <nevcairiel> if there is a week without feedback you're allowed to ask [10:47] <av500> nevcairiel: projects get created, forked and abandoned in less time than that on github :) [10:48] <anshul__> i posted first time, so dont know what to expect [10:50] <anshul__> what other people posted, there were lot of thing common. so i thought there wud be an format to send mail. like what is on linux!!! [10:50] <av500> git format-patch [10:50] <nevcairiel> its more like git send-email what he means [10:51] <durandal_1707> anshul__: read http://ffmpeg.org/developer.html [10:57] <anshul__> got it [12:02] <xlinkz0> i'm curious to learn how seeking works, how would i find out which function is pointed to by read_seek2 in avformat_seek_file? [12:03] <av500> depends on the format [12:03] <xlinkz0> this is from the report on the file i'm testing : [mov,mp4,m4a,3gp,3g2,mj2 @ 0xc08100] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100 [12:03] <av500> formats fill out callback functions [12:03] <av500> libavformat/movdec.c or so [12:03] <av500> or mov.c [12:04] <xlinkz0> thanks [12:05] <wm4> so I posted a patch for something nobody is interested in - how do I get someone to apply it? [12:11] <saste> wm4, ping it [12:11] <av500> advertise it [12:12] <saste> wm4, which patch? the icy thing? [12:12] <wm4> saste: yes [12:12] <saste> wm4, i'm going to review it [12:13] <wm4> thanks [12:21] <anshul__> i am unable to run ./tests/fate.sh doc/fate_config.sh.template [12:21] <anshul__> in my template file i have written [12:21] <anshul__> slot=anshul-i386-openSuse-gcc-4.7.2 20130108 # some unique identifier [12:22] <anshul__> but it is saying that "doc/fate_config.sh.template: line 1: anshul-i386-openSuse-gcc-4.7.2: command not found" [13:19] <wm4> ubitux: is there timed text subtitle support? [13:19] <wm4> appears it isn't [13:34] <saste> wm4, no way to read metadata from a protocol? [13:34] <saste> using options to read metadata is a bit weird [13:35] <saste> who is our libavformat protocols expert? [13:35] <wm4> saste: I don't know but I don't think there's metadata [13:35] <wm4> and in fact, cookies, content type, mime type are all communicated through avoptions [13:36] <saste> options are used for configuring components [13:37] <saste> usually they contain user configurations, rather than content information [13:37] <saste> not that i see a better solution at the moment [13:39] <wm4> yeah, I don't think this is particularly elegant [13:39] <wm4> in theory there should be some sort of out-of-band mechanism to transfer metadata, but then it gets too complicated [13:39] <wm4> especially for something as crappy/obscure as shoutcast metadata [13:44] <cone-855> ffmpeg.git 03Nigel Touati-Evans 07master:42bd0cd21ae6: Fix copying extradata to codec in mxfdec.c [13:46] <saste> wm4 i'm not against it, but then i'm no libavformat maintainer [13:46] <wm4> so who's responsible? [14:16] <Compn> wm4 : whoever wants to submit a patch :D [14:16] <wm4> since I came to the conclusion there's no nice way to implement it, I'm fine with my crappy patch [14:17] <wm4> crappy as in using avoptions to communicate content [14:17] <Compn> dumps it to a file ? [14:17] <Compn> or you mean modify metadata from avopts ? [14:18] <wm4> read [14:19] <wm4> the server sends the metadata, and I make it available through an avoption entry [14:19] <Compn> ah [14:19] <Compn> kind of like mplayers' get_property [14:20] <wm4> in mplayer it'd be a STREAM_CTRL [14:21] <Compn> like get property filename, get property ... metadata :P [14:22] <cone-855> ffmpeg.git 03Nigel Touati-Evans 07release/1.1:e2dcc4452dad: Fix copying extradata to codec in mxfdec.c [14:22] <cone-855> ffmpeg.git 03Nigel Touati-Evans 07release/1.2:fcc6460dbfcc: Fix copying extradata to codec in mxfdec.c [14:27] <Compn> whoa xvba decoder, nice [14:35] <JEEB> can someone confirm whether or not this vorbis stream is borked? it used to work before the check for the codebook entry count was added, but now it just errors out when initing the decoder [14:35] <JEEB> http://www.cccp-project.net/beta/test_files/possibly_broken_vorbis_stream.o… [14:35] <JEEB> and the audio seemed to sound OK when decoded [14:35] <Compn> on new or old version ? [14:36] <JEEB> pre-may 13th codebook entry count check [14:36] <JEEB> after that check was added it just seems to fail that check -> doesn't init decoder [14:36] <JEEB> if the sample's borked then I'll just push that to the person who provided the sample [14:36] <Compn> it works in mplayer 2012 and ffplay version N-52523-g0fb64da [14:37] <Compn> built on Apr 28 2013 00:01:23 with gcc 4.7.3 (GCC) [14:37] <JEEB> yeah, that's before the check [14:37] <Compn> although ffplay freezes a few times [14:37] <Compn> and loops [14:37] <JEEB> funky, works here on an april mplayer2 build [14:37] <Compn> with -demuxer lavf or mplayer demuxer ? [14:38] <JEEB> mplayer2/mpv use lavf demuxer by default [14:56] <JEEB> anyways, if anyone has the time to check the stream for correctness, I'd love it <3 [14:58] <wm4> xmms1 plays it [14:58] <wm4> it appears to use libvorbis (does that include a demuxer??) [14:59] <JEEB> most probably [17:28] <cone-855> ffmpeg.git 03Reuben Martin 07master:0de9d3dd1c73: gxf: Added GXF format code 25 which is used for DV codec in HD resolutions [17:28] <cone-855> ffmpeg.git 03Reuben Martin 07master:7ebf3ab959a0: gxf: Factorize code in get_sindex() [17:46] <cone-855> ffmpeg.git 03Reuben Martin 07master:c4db4b17569f: Added GXF format code to identify AVC Intra video streams. This was an extension to the origional GXF spec implemented by Grass Valley. [17:51] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:7eb6eb03d83a: lavc/mpegvideo_enc: simplify timestamp checks in load_input_picture() [18:15] <cone-855> ffmpeg.git 03Reuben Martin 07master:86190afbda0c: gxf: Added codec ID to playback AVCHD [18:57] <ubitux> wm4: you can do a av_asprintf() btw [18:58] <wm4> ok [18:58] <wm4> ubitux: about the subtitle utf-8 check, it seems nicolas didn't like the idea [18:58] <ubitux> s->icy_meta_header = av_asprintf("%s%s: %s\n", s->icy_meta_header ? s->icy_meta_header : "", tag, p); [18:58] <ubitux> or sth like that [18:58] <ubitux> without the leak [18:58] <ubitux> (not sure if that's simpler) [18:59] <ubitux> wm4: yeah, 'told you :p [18:59] <ubitux> dunno what to say except "i don't like it" [18:59] <JEEB> ubitux, do you know vorbis :V [18:59] <ubitux> i don't [18:59] <JEEB> k [18:59] <JEEB> will try to wait for someone who might know vorbis and check a sample's validity that used to decode before but now hits a sanity check [19:02] <wm4> how do I add private options to AVCodecContext? I want an option that can be set from outside, but I don't want to add an AVCodecContext member [19:12] <wm4> also why does avoptions have this complicated recursive option setting system, if you dump codec specific stuff into AVCodecContext anyway? [19:18] <Daemon404> JEEB, sanity check as in an assert? [19:19] <JEEB> a 'jooru' fix http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e6b6ae46951e242d7caf11acf5… [19:23] <wm4> ubitux: sorry, that's probably a rather basic question, but... how do I set sub_charenc_mode? [19:23] <wm4> -sub_charenc_mode pre_decoder doesn't work [19:24] <ubitux> i don't if you can do much with that [19:24] <ubitux> nicolas made me introduce it for a reason i forgot [19:24] <ubitux> i thought it was for internal purpose only [19:24] <ubitux> (but made "public" for interlib com) [19:25] <wm4> ............ [19:25] <wm4> sometimes I think you don't want applications to use your libs [19:25] <ubitux> but sorry, i forgot very quickly about stuff [19:25] <ubitux> and thus i don't remember that [19:25] <ubitux> so i might be wrong [19:26] <Compn> why you need to use it pre-decoder ? [19:26] <Compn> i mean, it doesnt work post decoder ? [20:27] Action: Daemon404 jumps in to help wm4 [20:29] Action: ubitux smiles with sympathy at his MUA [20:30] <Daemon404> i dunno, ive been working with subtitles for 8 years now [20:31] <Daemon404> i'd like to think my view is worth something. [20:31] <Daemon404> key bit: as a user [20:32] <ubitux> i didn't meant that way :) [20:32] <ubitux> i'm just happy to finally see subtitles talks [20:32] <ubitux> it's unfortunate i don't give a shit anymore [20:32] <Daemon404> i blame webtvv [20:32] <Daemon404> er [20:32] <Daemon404> webvtt [20:32] <Daemon404> feces. i meant feces. [20:33] <wm4> Daemon404: thank you [21:21] <kwizart> I don't understand the resolution of the libcdio support bug https://ffmpeg.org/trac/ffmpeg/ticket/2614 [21:21] <kwizart> it seems to me that the cdio/cdda.h isn't made available with libcdio-0.90 [21:22] <kwizart> I guess it's on purpose, but lot of projects still use them [21:29] <wm4> kwizart: from what I remember the default paths were changed around [21:32] <kwizart> wm4, probably also, or it has moved to another project ?: http://koji.fedoraproject.org/koji/rpminfo?rpmID=3732266 [21:32] <kwizart> because it's not anymore in libcdio [21:33] <kwizart> http://koji.fedoraproject.org/koji/rpminfo?rpmID=3714393 [21:33] <kwizart> the related cdparanoia package [23:26] <saste> foo = foo ? : 1; [23:26] <saste> valid syntax? [23:28] <ubitux> gnu extension afaik [23:31] <saste> ubitux, http://en.wikipedia.org/wiki/%3F:#C [23:31] <saste> yes [23:31] <ubitux> you have the av_x_if_null() that somehow allows this [00:00] --- Fri Jun 28 2013

1 0

ffmpeg.log.20130627
by burek 28 Jun '13

28 Jun '13

[00:43] <troker> Hey all, looking for an older copy of ffmpeg (version .60 to be exact) for some research. Anyone know where I might be able to find it? [01:32] <miguel_> is there a way to suppress the output from ffmpeg? [01:32] <miguel_> all the information about the process its doing [01:32] <miguel_> or pipe it to a file [01:33] <llogan> "-loglevel quiet" as a global option [01:35] <miguel_> thx [01:36] <llogan> or "ffmpeg -y -i input output 2> log.txt" [01:55] <whateverman> howdy [01:55] <whateverman> got some pretty vanilla issues, I think, this time [01:55] <whateverman> installing ffmpeg from source on amazon linux (since no repos are available for it that work well with amazon linux) [01:55] <whateverman> and I get to the point where I'm configuring ffmpeg - it says that it can't find libx264, though I installed that one from source [02:04] <whateverman> it might just be that x264 didn't build... bleh [02:06] <llogan> whateverman: how did you configure x264? [02:08] <whateverman> well, I've got /usr/local/lib/libx264.a [02:09] <whateverman> and it was configured with just "--enable-static" [02:13] <Zeranoe> I'm trying to do a screen capture using FFmpeg on Windows, but the audio is lagging the video behind. What audio codecs are very fast at encoding? [02:14] <llogan> maybe you can just stream copy it. [02:14] <Zeranoe> llogan: I don't think my hard drive is fast enough for raw pcm. What is the bitrate of pcm? [02:15] <sacarasc> 1440k. [02:15] <sacarasc> I think. [02:17] <whateverman> llogan: does that sound like I configured x264 correctly? [02:19] <llogan> patience. i have a million terminals open and i'm working on three servers at once. [02:19] <llogan> i mean 4. [02:20] <whateverman> no worries [02:20] <llogan> whateverman: add "--extra-libs=-ldl" to your ffmpeg configure [02:20] <whateverman> I'm only on 3 vOv [02:20] <whateverman> will try [02:21] <llogan> also see https://ffmpeg.org/trac/ffmpeg/wiki/CentosCompilationGuide [02:21] <whateverman> ah, tyty [02:21] <llogan> what distro is the amazon linux most like anyway? [02:22] <whateverman> centos [02:22] <whateverman> it's an RHEL-alike kinda like centos, but the repos don't quite line up [02:22] <llogan> maybe i should mention the amazon whatever on the centos guide then. [02:23] <bparker> how can I generate a video stream that's very difficult to encode? for example I'd think /dev/urandom would be a good source... but it seems I can't read from it fast enough for 1080p60 which is my requirement [02:23] <llogan> although i plan on merging them to make a general guide for linux, but i haven't arranged it so it is not too confusing for copy-n-paste users. [02:24] <whateverman> interesting - I had a script that worked unattended on some of our amazon linux servers, but I may have been taking a few things for granted that were already in place [02:24] <whateverman> that seems to have done it, llogan [02:31] <whateverman> again, thanks [02:34] <llogan> Zeranoe: maybe flac will fit your needs then [03:26] <whateverman> oh... and the reason I was re-compiling ffmpeg today [03:26] <whateverman> http://hastebin.com/fojigasixa.bash [03:26] <whateverman> this script [03:26] <whateverman> lol [03:26] <whateverman> one of my co-workers wrote it, then my boss ran it w/o options [03:26] <whateverman> if rm -rf / doesn't kill your server [03:26] <whateverman> chmod 777 / [03:26] <whateverman> will [06:06] <anshul> is it neccassory to do avcodec_close and avcodec_open if i want to mux video. [06:38] <RigidWig> is there a way to verbosely, one by one, declare the images to create a video? ie: ffmpeg -blahblahblah -i '1.jpg', '1234_abd.jpg', 'ZZX%^2.jpg' etc etc, rather than globing or sequencing....? [07:05] <Lyude> I have a Happauge Colossus capture card, and it happens to have a hardware x264 hardware encoder on it. There isn't any way I could have ffmpeg offload x264 encoding to that so that the CPU wouldn't have to do it, is there? [07:21] <vulture> Lyude: if it has a directshow driver you can probably hardware encode with directshow [07:22] <Lyude> This is on a Linux system [07:23] <vulture> does your hardware encoder have a linux driver? :P [07:23] <Lyude> Pretty sure it does, I'm not entirely sure though. I'm just wondering if ffmpeg has the ability to do this at all, since I know it can't do GPU encoding yet [07:24] <vulture> no idea [07:24] <vulture> most people I imagine dont bother with hardware encoding, it's usually lower quality [07:24] <vulture> and x264 is pretty fast these days [07:24] <Lyude> Streaming while gaming takes power though [07:24] <vulture> thats why you have multiple cpus [07:25] <Lyude> I've got a Q9550 overclocked [07:25] <Lyude> It still takes a lot of power no matter what :P, unless you're using hardware encoding, which I'd love to be able to do [07:26] <Lyude> I've gotta go for now, so I'll be back some other time, bai [07:27] <vulture> some hardware encoders probably can only even encode from their video capture ports too [07:36] <ilove11ven> Lyude: video encoder card is very cheap [07:36] <vulture> aaaaaaand that wasnt even his question [07:38] <ilove11ven> yes, he wants to stream his gaming. I suggest using video encoder card instead of GPU encoding [10:46] <anshul__> is there any spevific format. to send an patch, i feel mine patch is ignored on ffmpeg-devl mailing list [11:27] <rjek> Hi. Does anybody know if ffmpeg has a test suite of media files (specifically, broken media files) that's publically available? [11:36] <t4nk001> hi [11:37] <t4nk001> is it possible to skip frame in ffserver if the remote client can not receive data since tcp window size is zero [11:38] <t4nk001> when I use vlc to connect ffserver with the url http://192.168.1.254:8090/test.asf [11:38] <t4nk001> then vlc can not receive any data if tcp zero window is occur [11:38] <sine``> guys for windows, what would be the best codec pack to download [11:38] <t4nk001> is it possible to skip the frame if tcp zero window occur? [11:39] <t4nk001> in ffserver? [11:51] <t4nk001> any ideas? [12:41] <anshul__> cant run fate server, it is giving slote name as command not found [13:10] <kode54> is it me, or is ffmpeg.org incredibly slow right now? [13:12] <tsjiller> it's fast here [13:12] <tsjiller> 2013-06-27 13:12:03 (5,72 MB/s) - ffmpeg-1.2.1.tar.bz2 saved [5968378/5968378] [15:53] <mark4o> rjek: http://samples.ffmpeg.org/ [15:54] <rjek> mark4o: Does that include broken files, too? If so, you're my hero. [15:56] <mark4o> there are broken files in there [15:57] <rjek> :D [16:21] <ElInvitado1> hablan castellano? [16:22] <joltman> trying to do a screen capture with FFMPEG on Windows. using the dshow filter and the screen-capture-recorder app. The capture worked fine as x264 mkv. However, the machine i was capturing on rebooted last night to do windows updates. The capture stopped. I'm viewing the video now, but in VLC i can't fast forward. Is there a switch on the command line I need to add in order for FF to work? Let me find the command line I used to do this capture [16:25] <joltman> ffmpeg -f dshow -i video="screen-capture-recorder" -r 10 -threads 0 -t 28805 outfile.mkv [16:26] <joltman> i also am not getting a time length on the video when it plays in VLC. I'm wondering if this is because the FFMPEG process was killed by Windows [16:26] <joltman> oops...the frame rate was 15...not 10 [16:27] <Mavrik> hmm, not setting the encoding parameters usually isn't a wise idea :P [16:28] <Mavrik> but yeah, it seems ffmpeg didn't get the chance to write file trailer and set metadata [16:28] <Mavrik> so remux it and it should be ok [16:28] <Mavrik> basically just do [16:28] <Mavrik> ffmpeg -i your.mkv -codec copy new.mkv [16:31] <ElInvitado1> |-) [16:31] <ElInvitado1> the option -target ntsc-vcd does not work, always gives me VBR and has an unacceptable flashing Gibbs effect [16:32] <ElInvitado1> is there any solution? [16:32] <ElInvitado1> or I have to use TMPGEnc [16:33] <joltman> Mavrik: Thanks! [16:33] <joltman> i'm gonaa try this again [16:33] <joltman> thanks much! [16:36] <ElInvitado1> será TMPGEnc entonces [16:36] <ElInvitado1> chao [16:54] <mrAlmond> Hi everyone [16:54] <joltman> Mavrik: you were right, doing the -codec copy thing worked perfectly [16:54] <joltman> thanks for the help. Now I know what to do if Winderz decides to reboot again. [16:56] <mrAlmond> I've encoded an h264 using Android 4.2 encoder and then I've muxed it with ffmpeg to mp4 [16:57] <mrAlmond> it plays fine with vlc and mplayer in linux [16:57] <mrAlmond> but with windows media player it gives me error [16:57] <mrAlmond> this is the mp4box info of that file [16:57] <mrAlmond> http://pastebin.com/meP2Dfw8 [16:57] <mrAlmond> do you see something wrong? [16:59] <mrAlmond> this file has no audio track, only video [17:09] <xlinkz0> how do i check if a file was created with -movflags faststart? [17:15] <JEEB> xlinkz0, you can use for example L-SMASH's boxdumper and see how far in the file the moov atom is in [17:15] <JEEB> if it's in the beginning [17:15] <JEEB> it has the index moved into the beginning [17:16] <xlinkz0> is that a debian package? [17:16] <JEEB> dunno [17:16] <JEEB> not that compiling L-SMASH is hard :D [17:16] <JEEB> because it has literally no dependencies [17:16] <JEEB> other than a C99 compiler [17:30] <xlinkz0> JEEB: so moov: Movie Box] position = 32 means it is at the begining, right? [17:30] <JEEB> I think so [17:30] <xlinkz0> thanks [17:44] <mrAlmond> can someone give me some help? [17:44] <mrAlmond> http://pastebin.com/meP2Dfw8 [17:45] <mrAlmond> this file plays well on vlc but not on windows media player [20:02] <Maverick|MSG> does ffmpeg support encoding a file that is currently being written to? [20:02] <t4nk172> I am observing a weird behavior while using the H.264 Encoder (libx264). If I monotonically increase the pts "frame->pts++" before the avcodec_encode_video2() function, the encoder crashes randomly after encoding some 300 /350 odd pictures. However, if I implement PTs as a mod 128 counter i.e. frame->pts++; frame->pts %= 128, the encoder works fine. Any idea what could this be because of? [20:13] <llogan> Maverick|MSG: it's working for me (but first output/second input is DV) [20:19] <Maverick|MSG> llogan, so you have an input movie that is continuing to grow as the user is creating their movie and ffmpeg will encode it to x264 on the fly (and wait if it reaches the end of the file)? [20:21] <llogan> Maverick|MSG: i just ran: "ffmpeg -i input.dv -target ntsc-dv out.dv" and "ffmpeg -i out.dv out.mp4", but I didn't wait until the end since i'm currently encoding other stuff. [20:24] <Maverick|MSG> llogan I think the problem I'm running into is that ffmpeg is encoding the output file faster than the user is creating the avi [20:25] <Maverick|MSG> so I'm not sure if ffmpeg is going to stop encoding when it hits the end of the file, or pause at eof and check at a set interval if the avi is larger and then continue encoding, etc [20:26] <klaxa> i'm rather sure it will stop encoding at the point where the file ended when ffmpeg opened it [20:27] <Maverick|MSG> so no way to tell ffmpeg to just wait a little bit? [20:27] <Maverick|MSG> or recheck the source file? [21:25] <blink> is prores_kostya included by default in a windows build? [21:30] <llogan> blink: yes, probably as prores_ks [21:30] <llogan> see "ffmpeg -encoders" [21:30] <llogan> assuming you're using builds from Zeranoe [21:31] <llogan> and not some graybeard build [21:35] <blink> yes, I did. thanks, I was using a wiki page that stated prores_kostya. [22:31] <llogan> blink: was it a page on ffmpeg.org? [22:45] <blink> llogan: http://ffmpeg.org/trac/ffmpeg/wiki/vfxEncodingGuide#ProRes [22:52] <llogan> quite verbose [22:55] <blink> the specific incantation I was looking at was prefaced by "An example command line for generating a 2K mono clip with Prores is: " [23:06] <llogan> blink: thanks. i updated the guide to include both the new and older names. [23:07] <blink> thank you [23:07] <llogan> although that guide could use some cleanup/lowered verbosity. [23:08] <blink> I like the verbosity, as long as it's factual :) [23:16] <brontosaurusrex> so whats the difference between prores and prores_ks? [23:19] <llogan> brontosaurusrex: see "ffmpeg -h encoder=prores" and "ffmpeg -h encoder=prores_ks" [00:00] --- Fri Jun 28 2013

1 0

ffmpeg-devel.log.20130626
by burek 27 Jun '13

27 Jun '13

[00:03] <Daemon404> nevcairiel, i can NOT get relative samples paths to work [00:03] <Daemon404> it just says "samples location not specified" [00:06] <superware> I'm getting "Option mpegts_original_network_id not found." yet documentation says it exists [00:11] <Daemon404> finally... trial and error \o/ [00:24] <Daemon404> nope still failed [00:24] <Daemon404> because if the dir you run fate.sh from is dfferent than where make fate gets run [00:24] <Daemon404> it doesnt work [00:24] <Daemon404> what a shitshow. [00:25] <Daemon404> nevcairiel, what dir do you run it from? [00:49] <Daemon404> i wish carl would start putting hashes in ticket closes [00:54] <wm4> why not set it up such that trac listens on git commit? [01:08] <michaelni> wm4, lack of volunteer with free time (to investigate how to do it and to do it), also i should update trac to the latest version [01:10] <michaelni> i read that trac 1.0 has something called tracgit [01:10] <michaelni> but i dunno if thats related [01:10] <michaelni> the feature list sounds royally useless [01:11] <Daemon404> hey michaelni, a ffmpeg-specific change got clobbered in cllc.c [01:11] <Daemon404> during the latest set of merges [01:11] <Daemon404> (the ff_get_buffer thing) [01:13] <michaelni> Daemon404, which merge / file /line /hash ... [01:14] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9328ae484338b70a7f2dbcd420… [01:14] <Daemon404> specifically [01:14] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavcodec/cllc.c;h=797d… [01:14] <Daemon404> shouldnt have happened [01:18] <michaelni> Daemon404, oops, will fix [01:23] <michaelni> Daemon404, fixed [01:24] <Daemon404> cool. [01:26] <michaelni> j-b, was cone forgotten when the server was resurrected by the necromancers ? [01:28] <j-b> michaelni: no idea. I can ask [01:28] Action: j-b is in the USA, so I just landed and saw that the server was up [01:29] <michaelni> j-b, thanks! [01:30] <BBB-work_> yay j-b is alive [01:30] <BBB-work_> j-b, can't me meet in the south bay tomorrow? [01:30] <BBB-work_> sf is so far away [01:32] <j-b> BBB-work_: see with Alex [01:32] <j-b> he is the lead. [01:32] <j-b> michaelni: asked [01:32] <michaelni> j-b, thanks [01:52] <llogan> what happened to the server? [01:58] <Plorkyeran> there's a pretty standard trac plugin for updating tickets from commit messages that doesn't really need any configuration [02:00] <Plorkyeran> I think I ended up hacking together my own thing for Aegisub though [02:00] <Plorkyeran> since the standard plugin didn't set milestones based on what branch the commit is on [02:00] <Plorkyeran> and interacted weirdly with the github post-receive hook [03:17] <j-b> BBB-work_: well, I live in North SF, and the conf finishes late (7pm) and I am not motorized so, SF is way easier for me :) [03:19] <Compn> cant just meet up over skype [03:19] <Compn> have to meet in meatspace [03:29] <kierank> drinking beer over skype isn't as fun [03:42] <Compn> you ever done it ? [03:42] <Compn> dont knock it til you tried it [03:44] <kierank> yes [03:44] <kierank> it involved someone spilling a can onto their laptop [03:44] <Compn> sounds like fun :P [03:45] <Compn> also probably why should move to smokeable intoxicants, esp in california [03:46] Action: kierank doesn't do that [03:46] <kierank> drugs are bad mmkay [03:59] <Compn> deadly alcohol vs non toxic cannabis eh? [04:06] <drv> drink cola instead ;) [04:06] <kierank> both are good in moderation [04:07] <BBB> j-b: I don't think I can be in SF at that time, I have work, y'know? :) [04:26] <highgod> Hi, I want to ask a quesion.how can I get the number of slices in on frame? slice_group_count? thanks [09:27] <superware> should ffplay experience difficulties with an h.264-ts-udp stream? [09:27] <av500> with yours, yes [09:28] <superware> if I use VLC to save the stream to a .ts file (raw input -> file), ffplay plays it nicely [09:30] <superware> what does it mean? [09:50] <superware> can someone please help me? http://pastebin.com/ZyNxavHJ [10:01] <ubitux> -f h264 is wrong [10:01] <av500> there is already -f mpegts [10:02] <superware> well, it doesn't matter :( [10:04] <superware> actually it does, please see http://pastebin.com/VjK8dVah - now it doesn't even detect the stream properties [10:06] <superware> ubitux? [10:06] <ubitux> i don't know [10:08] <av500> Part of datagram lost due to insufficient buffer size [10:09] <superware> av500: udp://0.0.0.0:1234?buffer_size=100000 same [10:09] <av500> same error message? [10:10] <superware> "Part of datagram lost due to insufficient buffer size" yes [10:11] <superware> VLC plays it nicely, that's why I'm so frustrated [10:11] <av500> you know [10:11] <av500> ffmpeg could have a bug [10:13] <superware> well, if I'm using VLC to stream an h264-ts-udp stream, then ffplay plays it [10:13] <superware> I guess it's something specific to that stream [10:13] <av500> indeed [10:15] <superware> ok, so I thought maybe it's a problem with the format probing, so maybe it's possible to tweak options to make it work [10:15] <superware> because when VLC saved the raw stream to a file, ffplay handles it nicely, meaning the problem has something to do with udp [10:16] <michaelni> highgod, slice_num or current_slice [10:23] <highgod> oh, thanks michaelni [10:25] <highgod> I use if(code & 0x80) to detect whether this frame is start, if start, I push the previous slices in to queue [10:25] <highgod> is it ok? [10:25] <highgod> h264_probe [10:26] <cone-855> ffmpeg.git 03Carl Eugen Hoyos 07master:35aed74fdc7b: Use AV_RN32 for an unaligned read in the mxg demuxer. [10:26] <highgod> michaelni:our scale performance has been tested, I will submit the patch and the banchmark after I recheck it [10:39] <michaelni> highgod, shouldnt there be a AVParser to split things into access units [10:53] <highgod> michaelni:thanks, our app is get h264 slice bitstream from rtp stream, then send them to ffmpeg decoder. But I don't konw how many slices in on frames, so I have to detect the bit stream [11:14] <nevcairiel> Daemon404: i cheated and created a second empty samples directory relative to the run path so the check succeeds [11:15] <michaelni> highgod, the correct way to detect frame boundaries is described in the h264 spec, its a bit more complex than &0x80, but this correct detection should be implemented in the AVParser / shared with the AVParser [11:16] <nevcairiel> but dont try to understand the code in the h264 parser, it'll just give you a headache [11:43] <wm4> why does ffmpeg not use structs to define the contents of packet side data? [11:44] <av500> what does it use? [11:45] <wm4> stuff like AV_WL32 [11:46] <wm4> with a byte layout loosely defined in doxygen [11:47] <av500> isnt packet side data opaque? [11:47] <av500> aka just a blob? [11:47] <wm4> in theory it is, but it appears it's mostly used for "internal" communication from demuxer to decoder [11:47] <wm4> all within libav* [11:48] <wm4> (of course not with all side data types) [11:50] <av500> struct layout is compiler specific [11:50] <av500> no? [11:51] <wm4> I don't assume this form of packets is stored on disk or transferred between computers or even processes [11:54] <wm4> e.g. AV_PKT_DATA_PARAM_CHANGE is generated in libavformat/utils.c and read in libavcodec/utils.c, and that's it [11:54] <highgod> Hi, michaelni, can I use ffmpeg API to detect? is there any apis to implement this? [11:54] <av500> wm4: lavc and lavf are not married [11:54] <av500> one can use only one [11:55] <wm4> still makes a rather awkward API [11:56] <nevcairiel> yeah it was kinda silly to use [11:56] <nevcairiel> i had to deal with it a bit, and it didnt really feel good [11:57] <nevcairiel> but i'm done with that part now, so don't change it, or i'll have to touch it again! [11:57] <nevcairiel> :) [12:03] <superware> vlad_starkov: hi [12:54] <wm4> lol [12:54] <wm4> seriously [12:54] <wm4> complaining about removing copyright notices... from examples? [12:56] <cone-855> ffmpeg.git 03Carl Eugen Hoyos 07master:1235e91b3080: Require pthreads for compilation with OpenCL support. [13:14] <wm4> does anyone know genpts actually does? [13:14] <wm4> I've got a performance problem if pts jumps are involved (or at least that's what I expect) [13:15] <wm4> in that case it seems to read the whole stream until EOF before returning the next packet, or something equally silly [13:40] <nevcairiel> in my experience the pts it generates are not worth generating, they are usually pretty bad [13:47] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:87bc64893085: libavfilter/src_movie: fix which packet is reset [13:47] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:ee97982408c8: avfilter/src_movie: Fix handling of packet size for video [13:48] <michaelni> genpts generates pts from dts so it requires correct dts on all frames [15:15] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:034b31df2cd0: swscale: Fix PAL8 input with alpha [15:18] <ubitux> thank you michaelni for fixing all these bugs :) [15:55] <j-b> michaelni: cone is back. [16:25] <saste_> char tagbuf[32], cortag[32]; [16:25] <saste_> what is "cortag"?? [16:26] <ubitux> correct tag? [16:28] <saste_> ubitux, good guess [16:28] <ubitux> corguess [16:28] <saste_> i'm writing a transcoding example [16:29] <saste_> and fighting with various cryptic errors [16:29] <saste_> how should work this high-level API? [17:41] <michaelni> j-b, great, thanks [18:26] <saste_> what's the purpose of the chomp bitstream filter? [18:30] <saste> I mean in which cases is it useful? [18:51] <Daemon404> [05:14] <+nevcairiel> Daemon404: i cheated and created a second empty samples directory relative to the run path so the check succeeds <-- this is exactly what i did [18:51] <Daemon404> <_< [18:58] <saste> how can i annotate a patch? [18:58] <Daemon404> --annotate ? [18:59] <saste> Unknown option: --annotate [19:02] <Daemon404> it's part of git-send-email [19:02] <Daemon404> personally, i always format-patch first and just use vim. [21:30] <cone-855> ffmpeg.git 03Jean Delvare 07master:ff995e2b6f25: doc/filters: Fix texi syntax [23:31] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:3aa57e1582af: examples/muxing: remove useless instruction [23:31] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:c58d535b2f99: examples/Makefile: disable -O2 optimizations [23:31] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:47c9887ecaa7: lavc/utils: improve feedback in case of invalid packet size [23:31] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:08b99be7c474: lavf/mux: rename variable cortag -> tagbuf2 in init_muxer() [23:31] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:418b9454ff65: lavf/movenc: improve error feedback in case malformed AAC bitstream is detected [23:31] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:7b38c4c95f3b: doc/bitstream-filters.texi: add documentation for the aac_adtstoasc filter [23:31] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:db7ebab5c360: doc/bitstream_filters: document the chomp filter [23:39] <cone-855> ffmpeg.git 03Stefano Sabatini 07master:80b56a7bdd0f: examples/muxing: rename audio/video_pts to audio/video_time [00:00] --- Thu Jun 27 2013

1 0

ffmpeg.log.20130626
by burek 27 Jun '13

27 Jun '13

[00:06] <superware> I'm getting "Option mpegts_original_network_id not found." yet documentation says it exists [00:20] <llogan> superware: your ffmpeg/ffplay may be too old for the docs shown on the web site. refer to your local docs or upgrade. [00:24] <superware> llogan: "ffplay version N-54178-gbbe26ef ... built on Jun 24 2013" [00:27] <superware> llogan: http://pastebin.com/DDZdj08u [00:29] <superware> no visible video. yet vlc.exe udp://@:1234 works. [00:30] <llogan> why did you mention mpegts_original_network_id but then paste something else? [00:30] <superware> my guess is probing is poor in this case, so I need to somehow hint [00:31] <superware> no problem, a sec [00:32] <superware> here goes http://pastebin.com/tSYLj7dM [00:33] <llogan> try increasing buffer_size: http://ffmpeg.org/ffmpeg-protocols.html#udp [00:34] <superware> ... udp://0.0.0.0:1234?buffer_size=100000 - same [00:39] <superware> llogan: any idea? :| [00:39] <llogan> no [00:45] <superware> :( [03:21] <AisIceEyes> Hi! I'm a relatively new user of ffmpeg commandline and I'm trying to normalize an audio from a video. I saw this thread through searching - http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140826.html - And I'm wondering where do I get the script or where was it pushed to? Thanks! [03:28] <pandeiro> i'm trying to add srt subtitles to an avi file with `ffmpeg -i original.avi -vf subtitles=movie.srt out.avi` and it works as expected, but the output file is about 1/10 the size/quality. what do i need to change? [03:36] <AisIceEyes> pandeiro: you have to use an codec I think. Since it's an avi container, maybe XviD? [03:36] <AisIceEyes> pandeiro: http://ffmpeg.org/ffmpeg.html#Video-Options [03:37] <klaxa> pandeiro: ffmpeg encodes by default, to keep the original tracks, add: -c copy [03:37] <klaxa> oh wait... [03:37] <klaxa> you are hardsubbing, never mind [03:46] <pandeiro> yeah i am hardsubbing so i can watch an avi with subs on a tv without srt support [03:47] <pandeiro> AisIceEyes: is there no way to just use the same encoding as the original avi? [03:49] <klaxa> you can check what codec was used and use similar values [03:50] <klaxa> you can copy the audio at least [03:50] <klaxa> so there will be no quality loss [03:51] <AisIceEyes> pandeiro: What klaxa said :) [03:51] <pandeiro> ok [03:51] <pandeiro> any chance you could walk me through that this time? :) [03:52] <klaxa> pastebin what ffprobe -i original.avi outputs [03:53] <AisIceEyes> Hmm.... I've been wondering, is there a normalize filter in audio filters in ffmpeg? Maybe "normalize" is not the term? [03:53] <bencc> I'm using the following command: [03:54] <bencc> ./ffmpeg -i rtmp://127.0.0.1/audio/test -ar 44100 -f mp3 pipe:1 [03:54] <bencc> I only see the output when stopping the rtmp stream [03:54] <bencc> how can I make ffmpeg output result in real time? [03:54] <klaxa> AisIceEyes: see http://ffmpeg.org/ffmpeg-filters.html for all filters, maybe you'll find something? [03:55] <bencc> klaxa: hi [03:55] <bencc> klaxa: any idea how to use the rtmp_live option from here? https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2012-May/050143.html [03:55] <klaxa> bencc: hi, no idea, sorry :( [03:55] <bencc> just the syntax [03:56] <pandeiro> klaxa: http://sprunge.us/XbZZ [03:56] <klaxa> hmm still no idea, i've never dug through the ffmpeg/libav* source [03:57] <klaxa> pandeiro: try this: ffmpeg -i original.avi -vf subtitles=movie.srt -c:v libxvid -b:v 1900k -c:a copy out.avi [03:58] <pandeiro> klaxa: thanks, will do. curious: can i read about those on ffmpeg's man page or would they be described somewhere else? [03:58] <klaxa> read about what? the parameters? they should be documented in the manpage [03:59] <klaxa> in general the documentation on the website is maybe even more elaborate [03:59] <klaxa> http://ffmpeg.org/ffmpeg.html [03:59] <AisIceEyes> klaxa: Actually, I did checked that before going to this channel but to no avail. There is however a python script I found in the mailing list - http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140826.html - which I am not sure how to use or check Hmm... [04:00] <klaxa> i don't know how normalization works at all, maybe you could outsource the normalization to sox [04:00] <sacarasc> AisIceEyes: The script is found in the tools section of the source download. [04:00] <pandeiro> klaxa: ok. command is running but i notice some output: Neither PlayResX nor PlayResY defined. Assuming 384x288 [04:00] <pandeiro> is that relevant? [04:00] <klaxa> mmh probably? [04:01] <pandeiro> yeah seems :) [04:01] <klaxa> abort now, add -t 30 [04:01] <klaxa> then try to play the output [04:01] <pandeiro> add -t 30 to the command and run it? [04:01] <klaxa> yes [04:02] <klaxa> that will encode only the first 30 seconds so you can check whether or not it will work properly [04:02] <pandeiro> ah gotcha [04:04] <pandeiro> seems like it worked [04:04] <klaxa> ah good, then remove the -t 30 and encode the complete video [04:05] <pandeiro> that same ffprobe command should show the same resolution in the Stream #0.0 line? [04:05] <pandeiro> 720x400 in this case [04:05] <klaxa> then it should all be good [04:05] <pandeiro> cool thanks very much [04:05] <klaxa> np :) [04:23] <RigidWig> Say I wanted to have ffmpeg split and cut out segments of a video based on how dark (how much black, I suppose) those image frames contain (the video will be assmebled from jpegs), would ffmpeg have a native capacity to do this, or would I have to do that elsewhere and just serve up the array of selected files to ffmpeg? [04:26] <highgod> Hi, I want to ask a quesion.how can I get the number of slices in on frame? slice_group_count? thanks [04:40] <t4nk283> Hello there is a serious bug in ffmpeg that has been there for ages and i'm not having any luck getting anyone to look at it - if anyone is listening, interrupt_callback is not being fired at all anymore by any of the blocking methods which means that if you try to connect to a broken stream in windows and you dont specify a timeout then ffplay will hang indefinitely. [08:46] <t4nk327> ffmpeg is no longer calling interrupt_callback on blocking functions - any ideas? I've tried reporting it as a bug but no-one seems interested....? [08:59] <adnap> Hi [09:00] <adnap> How would I stream a video in .mkv format from one linux computer to another and play it using mplayer2? [09:00] <adnap> Also, is it possible to seek while streaming? [09:20] <superware> should ffplay experience difficulties with an h.264-ts-udp stream? [09:41] <superware> can someone please help me? http://pastebin.com/ZyNxavHJ [10:22] <superware> Mavrik: hi [10:34] <superware> can someone please help me with an h264-ts-udp stream (please see http://pastebin.com/ZyNxavHJ) it's perfectly playable using VLC... :| [10:36] <Mavrik> [udp @ 0180c820] Part of datagram lost due to insufficient buffer size [10:36] <Mavrik> this is your problem it seems. [10:52] <superware> Mavrik: I've also tried udp://0.0.0.0:1234?buffer_size=100000 but it's the same [10:53] <Mavrik> 100KB buffer? [10:53] <superware> I tried other sizes, it doesn't matter [10:54] <superware> ffplay can play the stream after I save it (raw) to a .ts file using VLC [10:55] <superware> the transmitter is doing something above the TS stream (udp packets etc) that VLC can handle, but ffmpeg not [10:55] <superware> maybe.. [10:55] <Mavrik> no [10:55] <Mavrik> the error is very clear [10:56] <Mavrik> your UDP buffer is being overrun and your packets are being corrupted [10:56] <Mavrik> VLC just has a bigger buffer it seems [10:56] <superware> how should I make the buffer larger? [10:58] <superware> http://ffmpeg.org/ffplay-all.html#udp [11:02] <superware> it seems fifo_size is very much related, now the errors are mostly "non-existing PPS 0 referenced" [11:19] <anshul_> i have some memory leak, when i am using livavformat. i do have valgrind lo, but i dont knoe where to paste [11:22] <anshul_> i have pasted the valgrind log over http://pastebin.com/ZAE83eaR [11:25] <microchip_> anshul_: if you think it's a genuine memory leak, open a bug report on ffmpeg's trac [11:32] <anshul_> how to report bug, ffmpeg's trac ??? [11:33] <saste_> anshul_, ^^ [11:35] <anshul_> got it ! [11:41] <dddh> is it expected to have cod running on GPU in near future? [11:41] <dddh> *code [11:56] <superware> Mavrik: can I unicast udp over the internet? [11:56] <Mavrik> yep [11:56] <Mavrik> dddh, code running on GPU? [11:59] <superware> Mavrik: can I stream is to you? :) I'll make it small bitrate [11:59] <Mavrik> er, why? [12:00] <superware> Mavrik: see if you're able to see it [12:04] <dddh> Mavrik: yes [12:05] <Mavrik> dddh, can you explain more about what do you mean about that? [12:15] <dddh> Mavrik: cuda computing? [12:16] <Mavrik> ah, no, there are no bigger plans, CUDA isn't really good for quality video encoding. [12:16] <Mavrik> there are some plans to integrate platform native libraries, but aren't very active [12:17] <TheSchaf> cuda sucks for stuff where you have to use ram [12:17] <TheSchaf> because cpu ram <=> gpu ram is the worst bottleneck [12:18] <Mavrik> and since execution units are limited on which ram they can access [12:18] <Mavrik> which really sucks for video-type pattern search on large frames :) [12:19] <dddh> heh [12:20] <dddh> current GPUs have enough RAM and there is dynamic parallelism since compute capability 3.5 [12:21] <dddh> you could load more data from host to device memory [12:22] <JEEB> there's a reason why everyone has started putting hardware encoders on GPUs instead of trying to use more GPGPU [12:23] <JEEB> MultiCoreWare together with AMD's support did do an OpenCL lookahead ME for x264, but 1) it is lower quality than the CPU algorithm, and 2) it only gives a ~10% increase of speed [12:23] <JEEB> GPGPU is good for some stuff, but not for the most used formats' video encoding [12:24] <dddh> I remember that story [12:25] <dddh> but my GPUs are more expensive than my CPU [12:25] <JEEB> that still doesn't change the fact that they are good for some stuff, and worse for other [12:26] <dddh> JEEB :) [12:27] <JEEB> and it's already a really good result that the lookahead ME is actually making it even a bit faster, even if it is of lower quality [12:27] <JEEB> anyways, I recommend putting GPGPU to use where it can actually be more useful :) [12:27] <JEEB> there are various things those things are good at [12:27] <Mavrik> I'd rather use efforts to integrate with platform encoding libraries [12:27] <Mavrik> way more useful and faster [12:28] Action: Mavrik puts "fix libstagefright" on TODO. :P [12:28] <JEEB> yeah [12:28] <JEEB> proper HW enc/dec support for the SOCs on mobile devices is a good thing [14:48] <FuseOnFire> ffmpeg-devel [14:54] <FuseOnFire> regarding ffmpeg for android - can that be used to stream/play rtsp streams (like with ffplay)? [14:56] <Mavrik> yes, it's not easy though. [14:56] <Mavrik> performacne isn't stellar either [14:58] <FuseOnFire> essentially I'm looking for a way to play rtsp streams with a low-delay (the android built-in videoView has latency in seconds in LAN) [14:58] <Mavrik> hmm [14:58] <Mavrik> what's your android target platform_ [14:58] <Mavrik> ? [14:59] <FuseOnFire> 4.x I guess [14:59] <Mavrik> your problem is basically severalfold: [14:59] <Mavrik> 1.) Alot of CPU's aren't fast enough for decoding and burn ALOT of power, ffmpeg doesn't have a working HW decoder support on Android [15:00] <Mavrik> 2.) Once you decode video you need to get frames on screen which can be pretty slow [15:00] <zap0> android doesn't have hardware. [15:00] <JEEBsv_> I think with 4.1/2 you could finally only use the HW decoder, so he could use ffmpeg or whatever to grab the data / demux, and then push that data to the HW decoder in his app [15:02] <Mavrik> yeah, that's why I asked about android platform version [15:02] <FuseOnFire> would ffmpeg be able to handle the rtsp streaming as ffplay can? [15:02] <Mavrik> since 4.1+ has APIs for HW decoder&. BUT. [15:02] <Mavrik> those APIs are mostly useless for widespread usage ATM :) [15:02] <Justin> Anyone have familiarity with using ffmpeg and direct show input? [15:04] <zap0> DS is shite. most hardware vendors provide their own libs. [15:04] <Justin> I know. I'm having the strangest issue. [15:05] <Mavrik> if anyone figures out how to detect which frame format is expected by the en/decoder on Android 4.1, I'd be very grateful though ;) [15:05] <zap0> the fact you think it should actually work is strange. [15:05] <Mavrik> zap0, are you just here for random trolling? [15:05] <zap0> no. [15:05] <Mavrik> Justin, it's easier if you just tell us what the issue is :) [15:06] <zap0> i have years of experiance with DS. i know its shite. [15:07] <Justin> Direct show directly to rtp multicast stream results a lot of dropped packets. Audio log shows they're old. If I take direct show to file, plays perfectly. I can then stream the file without a problem. If I take the direct show input to rtp, grab that stream with ffmpeg again and restream without re-encoding, the network speaker plays perfectly. [15:07] <Mavrik> hmm [15:07] <Mavrik> Justin, that looks more like network buffering issue than anything connected with DShow [15:09] <Justin> Here's the command line that I'm using. I've tried several other switches. Maybe you have a suggestion? ffmpeg -loglevel debug -f dshow -c:a pcm_s16le -ac 1 -ar 22050 -vn -i audio="Line In (USB Multi-Channel Audi" -c:a copy -f rtp "rtp://239.20.20.6:20222" [15:17] <Justin> Perhaps there's a buffer switch I've over looked that could be used? [15:18] <Mavrik> hmm [15:18] <Mavrik> I wouldn't know of any on RTP [15:19] <Justin> max delay is ignored by of framesize = 0, bufsize seemingly has no effect. async helps a little [15:20] <Justin> and the fact that if I grab the stream and rebroadcast, it just works just makes me a little insane. [15:21] <Justin> It's also not codec dependant. i encoded to ulaw and it does the same. [15:31] <nwave> is it possible to serve an rtmp stream from ffmpeg [15:50] <Mavrik> nwave, no, you'll need a streaming server. [15:51] <nwave> ok, I'm playing with crtmpserver. Having a bit of trouble doing a simple test on it. I assume I can just push an rtmp feed from ffmpeg to the streaming server? [15:54] <Mavrik> yep, that you can do [15:55] <nwave> http://pastebin.com/tuWjLUpt [15:56] <nwave> this is the crtmpserver error log when I try to send data to it [16:08] <Nunix> Hi all. I'm trying to decode an H264/MP3 RTMP live stream but I can't get my audio and video to sync. I can see after av_read_frame() that, after decoding, the audio and video PTS is sequential and appears correct but the actual audio that I hear is about 10 secs late. The video is perfect. Almost instantaneous. Is there any audio delay or buffer that I need to switch off? [17:10] <nwave> is it possible to publish to an rtmp server as well as saving the stream to disk using the segmenter [17:12] <JEEBsv_> you can have multiple outputs [17:13] <JEEBsv_> just set the first output file name/url/whatever and then start setting output setting again and then a second output file name/whatever [17:40] <nwave> this seems like it should work, but it's giving me http://pastebin.com/jNFg4jq5 [17:42] <JEEBsv_> well it is having a problem with the first output you are setting [17:42] <JEEBsv_> hmm [17:43] <JEEBsv_> is that segs/stream%05d.ts way of setting the output file name correct? [17:45] <nwave> yeah it works fine when used without the second output setting [17:45] <nwave> only got this error after trying to combine the outputs [18:50] <nwave> does anyone understand how the segment_list is created [18:51] <nwave> when I have segment_wrap enabled it just makes a really long file and never gets rid of old file entries [19:58] <t4nk096> Hi I have written an application using libavcodec (more specifically libx264) and am facing a segmentation fault issue that I am unable to debug. Would this be a correct forum to to enquire about the same? [20:20] <whateverman> so, question [20:20] <sdl240> 42! [20:20] <whateverman> clever [20:20] <whateverman> I was still typing [20:20] <whateverman> I've got some videos I'm concatenating, and I'm running into issues with the second video's audio dropping out [20:21] <whateverman> I'm converting the h264 encoded videos to ts files then using the concat filter [20:21] <whateverman> the second video has a mono audio track - how do I have it just use that as the L+R track and an empty L-R track for the latter part of the video? [20:52] <whateverman> so, is there a sane way to take a mono audio channel and upmix it to stereo for the concatenation [21:01] <llogan> whateverman: i may have missed an earlier discussion, but you can take a mono input and turn it into a stereo output with -map_channel or the pan audio filter. [21:01] <whateverman> ah [21:02] <whateverman> maybe you could help me with what I'm doing here [21:02] <whateverman> I'll get my scripts all together to show you if you'd care to take a look [21:02] <llogan> ok [21:03] <whateverman> http://hastebin.com/haduloqibe.bash [21:04] <whateverman> ffmpeg info [21:04] <whateverman> http://hastebin.com/lapukokeye.vhdl [21:04] <whateverman> this works to give me a video file of proper length without audio [21:05] <llogan> i'll just give you some examples [21:05] <llogan> ffmpeg -i mono.wav -map_channel 0.0.0:0.0.0 -map_channel 0.0.0:0.0.1 stereo.wav [21:05] <llogan> or [21:05] <llogan> ffmpeg -i mono.wav -af pan=2:c0=c0:c1=c0 stereo.wav [21:05] <whateverman> ah, ok [21:06] <mark4o> won't -ac 2 work if you just want to copy it to both channels? [21:07] <llogan> heh, yes. [21:07] <llogan> but what fun is that. [21:09] <llogan> whateverman: did you also see the concat demuxer? http://ffmpeg.org/ffmpeg-formats.html#concat-1 [21:09] <llogan> https://ffmpeg.org/trac/ffmpeg/wiki/How%20to%20concatenate%20%28join%2C%20m… [21:09] <whateverman> I did - trying to use that, things took a little long [21:10] <whateverman> I at least got it downmixing the stereo to mono when concatenating, now [21:10] Action: llogan curses the lack of CamelCaseUrl [21:10] <llogan> stereo to mono? i thought you wanted the opposite. [21:10] <whateverman> (finished version) http://hastebin.com/hibuwikage.bash [21:10] <whateverman> well, I was thinking that [21:11] <whateverman> then I realized that this was mainly for phones and tablets [21:11] <whateverman> I just needed it to match the audio tracks, and I was thinking that data should be preserved [21:11] <whateverman> but honestly, nobody cares about the audio quality on our videos [21:11] <whateverman> and phones have one speaker [21:12] <llogan> do you have any users that use headphones? [21:13] <llogan> although they probably won't notice either [21:26] <whateverman> actually, I'm being told that my video crashes browsers? http://alan.appredeemdev.com/out.mp4 [21:26] <llogan> mine just wants to download that [21:27] <whateverman> odd... works in android [21:28] <llogan> oh, you meant on a phone. duh. [21:28] <LithosLaptop> My browser just says the file is corrupt [21:30] <llogan> worked fine on iphone 3gs. [21:33] <AisIceEyes> <sacarasc> AisIceEyes: The script is found in the tools section of the source download. --> Would it be alright to ask where exactly? I don't think I see them anywhere here - https://ffmpeg.org/download.html [21:35] <llogan> download the ffmpeg source then look in the "tools" directory. [21:38] <AisIceEyes> llogan: Oh! There it is! Thanks! [21:38] <AisIceEyes> Though would it be alright to ask how to use in ffmpeg line? [21:39] <llogan> how to use what? [21:39] <AisIceEyes> *how to use it? [21:39] <AisIceEyes> I mean the py script [21:39] <AisIceEyes> Okay, you see llogan, I'm trying to normalize the audio of various files [21:39] <AisIceEyes> While encoding etc [21:40] <AisIceEyes> I have first found this through googling - http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140826.html [21:40] <AisIceEyes> Then there is the script [21:40] <AisIceEyes> I am not sure how to use the normalize.py you see ^^;; [21:47] <llogan> ./normalize.py input -c:v copy -c:a <your audio encoder> output [21:47] <AisIceEyes> So it's two commands? [21:48] <llogan> my example is one command [21:49] <whateverman> figured out what was up with that file [21:49] <AisIceEyes> I'm thinking if it's alright if it's possible to be something like this - ffmpeg -i input -filter:v "<can i insert the py here?>" -vcodec something <can i insert the py here?> -acodec something output [21:49] <whateverman> the audio track was mp2, so I had the last stage explicitly convert audio to aac [21:50] <AisIceEyes> Or at least call the python script [21:50] <AisIceEyes> Is it possible by chance? [21:50] <whateverman> you can always run ffmpeg from python [21:51] <AisIceEyes> Ah [21:52] <AisIceEyes> Thanks :) [21:53] <llogan> AisIceEyes: if you want to use the normalize tool you can use it like it is ffmpeg. just add your options as usual: normalize.py input <output options> output [21:53] <tkb> hi [21:54] <llogan> or you can look inside normalize.py and adapt it to your needs [21:56] <AisIceEyes> llogan: Ah, I think I can do that. Though I don't understand most of the algorithm yet. Will just study it. Thanks :) [21:57] <AisIceEyes> Just to be clear, there is no way to run the py script in ffmpeg? [21:57] <llogan> no [21:57] <AisIceEyes> llogan: Gotcha. Thanks :) [21:58] <tkb> i got a problem: when i try to encode an flv video to mp3 with ffmpeg -i vid.flv -acodec libmp3lame -ab 320k out.mp3 (CBR) it encodes the video to mp3 ...but in some players like audacious or winamp, die duration of the song will be reported wrong and seeking is impossible ... i did read a little bit and found out that the reason is that ffmpeg does not set the xing header in CBR mp3 Files correctly.... how can i set them correctly throu [21:58] <tkb> gh ffmpeg ? [22:05] <hypfer> yäy [22:05] <hypfer> hello everyone [22:06] <hypfer> i have some broken flac files. mplayer doesn't care, but rhythmbox won't play them. I just want to reencode them with no quality loss. [22:06] <hypfer> are there special parameters for that? [22:18] <llogan> hypfer: ffmpeg -i input.flac output.flac [22:18] <hypfer> hm [22:18] <hypfer> simple [22:42] <pyBlob> Is there a way to convert color-mjpgs to grayscale-mjpgs by just leaving out/overriding the U/V-components? [22:44] <pyBlob> -> no encoding error for Y-component [00:00] --- Thu Jun 27 2013

1 0

ffmpeg-devel.log.20130625
by burek 26 Jun '13

26 Jun '13

[00:00] <cone-409> ffmpeg.git 03Derek Buitenhuis 07master:d48f22195203: cllc: Implement YUV support [00:00] <cone-409> ffmpeg.git 03Derek Buitenhuis 07master:61c82214afac: cllc: Use outbuf in RGB and ARGB functions [00:14] <cone-409> ffmpeg.git 03Matthew Heaney 07master:bc35df29c123: lavf: add AV_DISPOSITION flags for WebVTT text track kinds [00:14] <cone-409> ffmpeg.git 03Matthew Heaney 07master:1029822a91c2: lavf/webvttdec: use private option to specify WebVTT kind [00:21] <wm4> so can ffmpeg mux webvtt into webm yet? [00:21] <ubitux> not yet [00:21] <ubitux> there is a patch, matthewjheaney_ needs to rebase and maybe rework it i don't remember [00:22] <ubitux> then someone needs to make a translation of the chaptering in webm through webm [00:22] <ubitux> that's gonna get funny... [00:22] <Daemon404> doesnt everyone use mkvmerge to make webm anyway? [00:22] Action: Daemon404 runs [00:23] <wm4> ubitux: chaptering? [00:24] <ubitux> yeah well you know there is chapters in mkv [00:24] <ubitux> in webm it seems to use... a webvtt thing [00:24] <ubitux> but maybe i misunderstood something [00:24] <Daemon404> eh? [00:24] <Daemon404> why not just use matroska chapters [00:24] <Daemon404> other than idiocy [00:24] <ubitux> don't take my word on this [00:25] <ubitux> but the patch above are all about a "kind" of webvtt [00:25] <Daemon404> they all sounds horribly scary to me [00:27] <beastd> Wasn't part of the WebVTT idea to *not* mux the subtitles (erm captions they say) into the file but have them as separate files on the webserver. Not that I would really understand that because subtitles are usually the smaller problem in size compared to everything else in a movie file... [00:28] <Daemon404> beastd, thats what we plan to do [00:28] <Daemon404> since we plan to use webvtt with h264/mp4 [00:28] <ubitux> honestly, having them muxed is a good thing [00:28] <ubitux> Daemon404: wat [00:28] <Daemon404> html5 -> h264 [00:28] <Daemon404> nobody gives a shit abou vp8 [00:28] <ubitux> soon vp9 [00:29] <Daemon404> indeed [00:29] <ubitux> and you're gonna help for that in august afaiu [00:29] <Daemon404> im not helping cause i think vp9 will go anywhere [00:29] <Daemon404> i helping out of interest [00:29] <Daemon404> :P [00:29] <ubitux> also webvtt into mp4 update your flashplayers, hf [00:29] <Daemon404> that doesnt allow users to easily change captions. [00:29] <Daemon404> its worse in every conceivable wa [00:29] <Daemon404> y [00:30] <Daemon404> not to mention mp4 doesnt officially support webvtt. [00:30] <Daemon404> (iirc) [00:31] <ubitux> of course it doesn't :P [00:40] <kierank> Daemon404: it will soon [00:40] <kierank> mpeg is standardising it [00:40] <Daemon404> oci [00:40] <Daemon404> er [00:40] <Daemon404> oic [00:40] <Daemon404> doesnt make it any less insane (dat inline css) [00:40] <wm4> Daemon404: put webvtt in movtext lol [00:40] <wm4> this webm thing seems to turn into some "how to make matroska even worse" thing [00:42] <ubitux> Daemon404: up-rounded shift [00:42] <Daemon404> ubitux, the negative int trick is a bit confusing [00:43] <Daemon404> if you havent seen it before [00:43] <ubitux> it's doxy commented in the pix desc [00:43] <Daemon404> well thats in pix desc :P [00:43] <Daemon404> not BB's patch [00:43] <Daemon404> BBB* [00:43] <ubitux> it's all over the code base as FF_CEIL_RSHIFT() now [00:43] <Daemon404> yeah but its commented by FF_CEIL_RSHIFT [00:44] <Daemon404> where it should be, no? [00:44] <ubitux> that's why i suggested the macro [00:44] <Daemon404> yeah [00:44] <Daemon404> im agreeing with you here man. [00:44] <ubitux> i like to argue with the agreeing [00:44] <ubitux> it doesn't sound good otherwise [00:44] <Daemon404> lol [00:45] <BBB-work_> omg macros [00:45] <BBB-work_> I recall someone recently trying to add a macro to libvpx to test whether a number is odd or not [00:46] <BBB-work_> you guys want to update the patch for me, or you need me to spoonfeed it? [00:46] <Daemon404> i can update and push [00:46] <BBB-work_> ty [00:46] <Daemon404> if ubitux or w/e is ok w/ it [00:46] <wm4> <Daemon404> ubitux, the negative int trick is a bit confusing <- isn't that undefined behavior in C? [00:47] <Daemon404> shifting a negative? [00:47] <BBB-work_> no, it's perfectly well-defined [00:47] <BBB-work_> (right-shifting) [00:47] <BBB-work_> I think left-shifting could be an issue, although sufficiently many people use it that no compiler would ever want to break it in practice [00:47] <ubitux> Daemon404: assuming that change, i have no other comment on the patch, i don't know if that's correct or not [00:48] <Daemon404> maybe michaelni can say. [00:48] <wm4> huh, so right-shifting a negative is well defined [00:48] <kierank> BBB-work_: it surprises me how many people don't know what x&1 does [00:48] <kierank> it's probably the first ever idiom you learn [00:48] <ubitux> haha [00:49] <wm4> the C standard reads: "If E1 has a signed type and a negative value, the resulting value is implementation-defined." [00:49] <wm4> so it's not exactly undefined [00:49] <ubitux> < BBB-work_> omg macros // you don't like FF_CEIL_RSHIFT()? :( [00:49] <wm4> but still platform dependent [00:53] <durandal11707> convert all macros to inline functions? [00:55] <BBB-work_> ubitux, for me, it falls in the category of #define INCREMENT(x) x++ [00:56] <Daemon404> BBB-work_, i wholeheartedly disagree [00:56] <BBB-work_> ubitux, but that's just a personal opinion, it's fine if you guys like it more [00:56] <Daemon404> it's a non-straightforward thing [00:56] <Daemon404> which is used in many places [00:56] <BBB-work_> it's fine, I don't mind [00:56] <BBB-work_> I wouldn't do it myself, as you can see, but I can live with it [00:58] <beastd> i think macros are overused in ffmpeg. for that particalur example i think it is OK though. [00:58] <BBB-work_> kierank: I can say nothing more but just "eek" [01:00] <Daemon404> dude [01:00] <Daemon404> the vast majority of programmers dotn even know the difference between the stack and heap [01:01] <Daemon404> if we're gonna go dont the incompetence road... ;) [01:01] <BBB-work_> the vast majority of programmers dont code in c :) [01:02] <Daemon404> i havent been coding much C myself lately [01:02] <Daemon404> a lot of Go [01:02] <Daemon404> hurr durr [01:03] <ubitux> BBB-work_: this macro has multiple purpose; biggest one being that it documents what this bithack does, second one is that it allows a fast path in some cases (and another one might be to make a new version of that bithack if the neg shift appears to be badly supported) [01:04] <j-b> The amount of stupidity this WebVTT thing is, is beyond anything else... [01:05] <ubitux> haters gonna hate [01:05] <Daemon404> j-b, i agree [01:07] <BBB-work_> ubitux, sure, I'm fine with it, will you guys update my patch for me ? :) y4m is still broken for odd yuv sizes [01:07] <ubitux> i thought Daemon404 was doing it [01:07] <Daemon404> well i can update it [01:07] <ubitux> but it seems he's busy messing the libav tree right now [01:08] <Daemon404> shhhhhhhhhhh [01:08] <Daemon404> leave my fuckups alone [01:08] <Daemon404> :( [01:08] <ubitux> ;) [01:08] <BBB-work_> should I go check what he did this time? [01:08] <BBB-work_> this can only be fun [01:08] <Daemon404> BBB-work_, i pushed a fate test patch too early [01:08] <Daemon404> by accident [01:08] <j-b> ubitux: you can justify that 4 different tracks type? [01:09] <ubitux> j-b: nope [01:09] <ubitux> i'm mostly concerned about the way it's muxed in webm right now [01:09] <ubitux> like "let's use \n as a binary field separator" [01:13] <wm4> uh what [01:13] <beastd> good night... [01:14] <ubitux> wm4: each "cue" in webvtt can contains an identifier, timestamps, settings, and payload [01:14] <ubitux> in a standalone .vtt, it's like that: [01:14] <ubitux> identifier [01:14] <ubitux> timestamp - settings on same line [01:14] <ubitux> payload [01:14] <ubitux> so basically you have AVPacket with a payload and classing timestamp in pts [01:14] <ubitux> and 2 side data for identifier and settings [01:15] <ubitux> but in webm, it muxed like this: identifier\nsettings\npayload [01:15] <wm4> so why is that stuff in side data and not the packet itself? [01:15] <ubitux> so basically it's reconstructing a strange string like thing [01:15] <ubitux> wm4: it doesn't really belong in the payload [01:16] <ubitux> having identifier\0settings\0payload or something like that would make more sense in webm IMO [01:16] <Daemon404> BBB-work_, new patch sent then [01:16] <BBB-work_> \o/ [01:17] <ubitux> wm4: assuming a muxer is muxing webvtt differently (like using an appropriate fields placement for identifier or settings), this weird string representation doesn't make much sense [01:17] <wm4> I don't understand why it can't be in the payload [01:17] <ubitux> we could have use it from the beginning for packets going out of WebVTT demuxer, but how could we guess webm was going to mux it as such [01:18] <ubitux> well, we could do it, but that's not that intuitive; you might have sometimes payload with 2 \n or stuff like that [01:18] <wm4> and... [01:18] <ubitux> the payload is supposed to contains the text, the other things are extra [01:19] <ubitux> you don't know how that info is going to be muxed in different containers [01:19] <wm4> ASS also has additional things in the payload [01:19] <ubitux> basically .vtt and .webm mux them differently [01:20] <ubitux> wm4: i couldn't have guess that the formats of the packets should be as such when i added the demuxer [01:20] <ubitux> it also makes the muxers need to split those string again [01:20] <ubitux> which is counter productive [01:20] <ubitux> (and would introduce a behaviour break btw) [01:23] <BBB-work_> ubitux, can you ok and push derek's patch, given you're the CEIL_RSHIFT expert? [01:23] <BBB-work_> you seem like the ultimate dude to review that patch [01:23] Action: ubitux ceil rshift expert yay [01:24] <BBB-work_> better watch out, before you know it you're the threading expert :) [01:24] <wm4> I just find it strange how matroska did without side data all the time, and now it suddenly requires many side data types [01:24] <BBB-work_> oh right I was going to write a blog post about that [01:24] <Daemon404> there [01:24] <Daemon404> michael ok'd it [01:24] <Daemon404> ill push it bbb [01:25] <BBB-work_> \o/ [01:25] <BBB-work_> ty guys [01:25] <Daemon404> running FATE first [01:26] <Daemon404> (do we even have y4m tests?) [01:26] <ubitux> wm4: bitstream filters, ugly string hacks (remembers srt?), ... ? [01:26] <BBB-work_> they probably don't use odd frame sizes :( [01:26] <ubitux> we don't have 'nuff odd size tests [01:26] <BBB-work_> that's b/c many media formats don't support odd frame sizes [01:27] <ubitux> especially with some cool pixfmt where chroma shift mismatches [01:27] <BBB-work_> e.g. h264 :) [01:27] <Daemon404> BBB-work_, even 4:4:4? [01:27] <BBB-work_> true [01:27] <Daemon404> or its faux RGB [01:27] <BBB-work_> heh :) [01:27] <BBB-work_> I meant 420 obviously, but yes you're right [01:27] <Daemon404> ;P [01:27] <cone-409> ffmpeg.git 03Ronald S. Bultje 07master:cea8a0077fc5: yuv4mpeg: correctly handle chroma for odd luma sizes. [02:40] <wm4> durandal11707: would this an acceptable patch? http://sprunge.us/MTIV [03:27] <durandal11707> wm4: it works? [03:27] <wm4> yes [03:28] <wm4> of course it requires the application to go out of its way to use it [03:28] <durandal11707> how? [03:28] <wm4> it first has to enable icy by setting the option [03:29] <wm4> then it has to read icy_meta_header and icy_meta_packet per option API [03:29] <wm4> for icy_meta_packet it has to poll frequently [03:29] <wm4> to see whether it has been updated [03:31] <durandal11707> hmm, send it to ml, i really don't have opinion on this [03:32] <wm4> ok will do so tomorrow or so [10:11] <j-b> BBB: BBB-work_: I am in SF starting today. [11:10] <michaelni> git.videolan.org is down [11:14] <michaelni> until videolan is up again my work is at: https://github.com/michaelni/FFmpeg.git/ [11:15] <michaelni> feel free to send me pull requests as usual [11:15] <michaelni> ill merge / push it all to videolan once that is up again [13:03] <JT-EC> Is --disable-swscale supposed to work and when it does should an ffmpeg binary be produced or does the actual ffmpeg binary depend on swscale so doesn't build without it? [13:09] <nevcairiel> i think it depends on it [16:05] <superware> I have a H.264 TS over UDP, "vlc.exe udp://@:1234" works while "ffplay udp://127.0.0.1:1234" shows nothing but lots of errors such as "fPES packet size mismatch" etc, any ideas? [16:13] <kierank> probably a slightly out of spec ts [16:17] <av500> superware: have a sample? [16:19] <superware> +av500: will be difficult. should ffplay show a h264-ts-udp stream? [16:19] <av500> probably [16:20] <superware> because VLC's syntax that works is udp://@:1234 but ffplay doesn't [16:20] <superware> VLC doesn't work with udp://127.0.0.1:1234 ... [16:21] <superware> maybe I'm missing ffplay's syntax for VLC's udp://@:1234 [16:21] <av500> it works [16:21] <av500> you are getting the stream [16:22] <av500> otherwise you would see no " "fPES packet size mismatch" errors [16:22] <superware> you have a point there [16:23] <superware> I can show you the log, ok? [16:23] <superware> it's all errors, it deosn't seem it recognizes anything [16:24] <av500> log is no help [16:24] <av500> captured stream would be help [16:24] <superware> is it possible with ffmpeg.exe? [16:24] <superware> to capture.. [16:27] <superware> +av500: can I send you the .ts file? [16:28] <superware> +av500: ffplay can play the .ts ... wtf? [16:30] <superware> +av500: please.. [16:31] <ubitux> superware: http://ffmpeg.org/bugreports.html [16:32] <ubitux> in the case of PAL8, sws needs palette in data[1], right? what about linesize[1]? is 0 fine? [16:32] <superware> ubitux: the raw TS data is playing with ffplay, but when I try directly from UDP it doesn't. [16:33] <ubitux> then debug it, or report a bug [16:36] <superware> say, for VLC the url that works is udp://@:1234 but udp://127.0.0.1:1234 doesn't. which is the correct one for ffplay? [17:55] Action: michaelni stares at cone [17:55] <michaelni> where is cone ? [17:59] <JuxTApose> Can anyone link me to some source code that efficiently handles video playback caching at the frame level from the ffmpeg linked libraries? thanks [18:00] <JuxTApose> i am working on a side effect in blender's video game engine video texture playback file... [18:01] <JuxTApose> it's linking to ffmpeg and looping in seconds not frames so a seamless animation does not loop properly [18:01] <JuxTApose> the offending line looks like #768 in http://www.letworyinteractive.com/blendercode/d1/d9a/VideoFFmpeg_8cpp_sourc… [18:01] <JuxTApose> it looks like it tests seconds instead of frames so the last few frames are skipped making the animation loop not seamless... [18:02] <JuxTApose> this is not noticeable in loops that are not seamless [18:04] <michaelni> JuxTApose, ffplay has fifos between the threads if thats what you are searching for [18:05] <JuxTApose> michaelni: ya, that is just where I started looking... [18:05] <JuxTApose> it looks promising... [19:20] <BBB-work_> j-b, cool! [20:20] <llogan> what OS are missing from FATE currently that we may want? [20:56] <llogan> 93 comments. is that the record? [21:00] <durandal_1707> michaelni: please don't merge pcm stuff from fork [21:15] <michaelni> llogan, we want all from https://en.wikipedia.org/wiki/List_of_operating_systems on which ffmpeg could be build & run [21:18] <michaelni> or said difefrently "all os" that can be supported and arent yet on fate and that have a vulunteer willing to setup fate [21:18] <Daemon404> plan9. [21:19] <Daemon404> mru ported lbav to plan9, and its in platform.html [21:19] <Daemon404> i dont think anyone tried ffmpeg. [21:19] <Daemon404> and there is no FATE iirc [21:19] <Daemon404> for either [21:19] <Daemon404> http://ffmpeg.org/platform.html#Plan-9 [21:35] <superware> this http://pastebin.com/bFUvBwHU is what I get when trying to ffplay an h.264-ts-udp stream, which actually plays nicely in VLC (udp://@:1234), any ideas? [21:42] <saste_> how are we supposed to handle the case when the av_log buffer is too short? [21:47] <superware> saste_: mine is short? :) [22:05] <Daemon404> https://vimeo.com/69111871 [22:10] <ubitux> write a batch script! [22:12] <Daemon404> lol [22:12] <Daemon404> i assume you saw the emails i get ubitux [22:12] <Daemon404> the very useless vague ones [22:12] <ubitux> yes [22:13] <ubitux> the print in cmd.exe is particularly fast haha [22:13] <Daemon404> you mean the end of the configure? [22:13] <Daemon404> its actually instantanious [22:13] <Daemon404> but virtudub slowed it down whe ncapturing [22:13] <ubitux> ok [22:14] <Daemon404> im still bothered by how bad the chroma subsampling went [22:14] <Daemon404> libutvideo's yv12 subsample algo is so bad [22:19] <durandal_1707> thats why assembly optimizations are still missing in native version [22:21] <Daemon404> durandal_1707, ? [22:21] <Daemon404> for what? [22:22] <durandal_1707> i read from time to time on doom9 how native utvideo is slow [22:22] <Daemon404> oh [22:22] <Daemon404> native utvideo (upstream) has ASM [22:22] <Daemon404> but it also has its own color conversion algos [22:23] <Daemon404> which are terrible. [22:23] <Daemon404> all of its asm is for huffman and stuff [22:23] <durandal_1707> libavcodec/utvideoenc.c ? [22:24] <Daemon404> yeah but i captured using virtualdub [22:24] <Daemon404> which needs VFW codecs [22:24] <Daemon404> bascially, i should have just captured in RGB. [22:25] <JEEB> that's the nr1 rule in screen capture [22:25] <JEEB> if you're going to do it, do it in RGB [22:25] <Daemon404> yeah [22:25] <JEEB> you can then proceed to raping it in any way you want [22:25] <durandal_1707> what a mortal sin, using virtualdub for capturing.... [22:25] <Daemon404> actually [22:25] <Daemon404> it has the best capture code of anything [22:26] <Daemon404> http://www.virtualdub.org/blog/pivot/entry.php?id=356 <-- [22:26] <Daemon404> dxgi is great [22:50] <superware> I have an h264-ts-udp stream being played by VLC --demux ffmpeg udp://@:1234 but not by ffplay udp://127.0.0.1:1234 (log at http://pastebin.com/4navfRNM) [23:11] <saste_> #define AVERROR_EXPERIMENTAL (-0x2bb2afa8) ///< Requested feature is flagged experimental. Set strict_std_compliance if you really want to use it. [23:11] <saste_> this is soo libav: it is experimental, ergo is an error [23:13] <Daemon404> saste_, its used for -strict [23:13] <Daemon404> and yes that SHOULD error unelss explicitly told "i want broken things [23:13] <Daemon404> " [23:14] <wm4> it's always nice if libavcodec tells users to use certain flags, even though the host application has completely different command line options [23:16] <saste_> an error code which tells the user to use a flag... not so a good idea [23:16] <saste_> especially if you have no idea where you are supposed to set that option [23:16] <Daemon404> sorry, it should not allow use of shit like the vorbis or aac encoders by default [23:16] <Daemon404> that just asking for trouble [23:17] <wm4> "The %s '%s' is experimental but experimental codecs are not enabled, " [23:17] <wm4> "add '-strict %d' if you want to use it.\n", [23:17] <wm4> ^this message [23:17] <saste_> Experimental feature => since when an experimental feature should be considered like an error? [23:17] <saste_> it is because of bullshit like this that user interfaces and feedback tend to be shitty [23:17] <Daemon404> i cant tell if youre arguing semantics, or if you really truly think we should allow users to use it without issue [23:18] <saste_> (not to mention the most silly option name ever: -strict) [23:18] <Daemon404> the interface and message are silly, the concept is correct [23:18] <Daemon404> personally i dont even think we should enable or include such broken garbage [23:18] <Daemon404> but hey. you guys want it. [23:19] <wm4> Daemon404: I agree [23:19] <wm4> and this should be done for bad quality encoders as well [23:19] <wm4> even if they're stable [23:19] <Daemon404> there already under experimental [23:19] <Daemon404> because theyre so shitty [23:19] <wm4> and while we're talking about default settings [23:19] <wm4> I think ffmpeg.c by default still produces really... bad results [23:20] <Daemon404> low quant terrible mpeg4? :) [23:20] <Daemon404> yeah i dont know why. [23:20] <Daemon404> er [23:20] <Daemon404> high quant. [23:22] <Daemon404> http://xiphmont.livejournal.com/51160.html [23:22] <Daemon404> there it is. [23:22] <Daemon404> i knew monty wrote something on it. [23:22] <wm4> ow [23:23] <wm4> so... just why does ffmpeg's build system not detect dependencies by default [23:23] <Daemon404> actually i kind of like that [23:23] <Daemon404> auto-enablign deps wa the bane of my existence [23:23] <wm4> this is impractical enough that I consider to write a script on top of ffmpeg to detect and enable these automatically [23:23] <Daemon404> its actually a terrible idea IMHO [23:24] <wm4> every other build system in existence does it [23:24] <Daemon404> and it has cause no shortages of MASSIVE headaches [23:24] <Daemon404> for distro and package maintainers [23:24] <Daemon404> when i did stuff for #oe it wa te problem 99% of the time [23:24] <Daemon404> for parallel build issues [23:25] <Daemon404> nondeterinistic behavior depending on when optional autodetected/enabeld deps are buily [23:25] <Daemon404> built* [23:26] <saste_> Daemon404, i'd like to be able to set policy like configure --set-enable-policy=auto [23:26] <Daemon404> saste_, that seems reasonable [23:26] <wm4> yes, even so, it would be nice if autodetection could be enabled [23:26] <Daemon404> but should not be default [23:27] Action: Daemon404 enables x64 ICL FATE for ffmpeg [23:43] <superware> how should I ffplay a h264-ts-udp stream? [00:00] --- Wed Jun 26 2013

1 0

ffmpeg.log.20130625
by burek 26 Jun '13

26 Jun '13

[02:58] <bencc> does the static build include rtmp support? [03:03] <Zeranoe> FFmpeg seems to be speeding up the video when it is encoding, the input is an avisythn script [06:49] <ilove11ven> bencc: yes [07:17] <bencc> ilove11ven: I'm trying to save rtmp stream as flv file with [07:17] <bencc> ./ffmpeg -loglevel debug -i rtmp://127.0.0.1/oflaDemo/test test.flv [07:17] <bencc> but getting: Operation not permitted [07:18] <bencc> full output: http://dpaste.com/1269876/ [07:18] <bencc> so I thought maybe rtmp support is missing [08:27] <ilove11ven> bencc: it seems to be an accessibility error on server. Just wireshark it. [08:29] <bencc> ilove11ven: I've tried with both rtmplite and red5 [08:29] <bencc> I'll use wireshark. thanks [08:31] <ilove11ven> bencc: So they both worked. I have dumped rtmp stream from Adobe's server 4.0. May I know what server are you using? [08:33] <bencc> tested rtmplite and red5 [08:34] <bencc> both don't work for me [08:34] <bencc> I'm able to publish and play with browsers [08:34] <bencc> but can't use ffmpeg with it [08:37] <bencc> ilove11ven: does ffmpeg support the nellymorser codec? [08:37] <bencc> I wasn't sure so I used speex [08:37] <ilove11ven> ok. maybe we could check the dump, and see what happened. [08:38] <steinchen> moin.. id like to take a shot every 3 seconds... for 5 seconds i use -r .2 .. and for 3? [08:38] <bencc> ilove11ven: what dump? [08:38] <ilove11ven> wireshark [08:39] <bencc> ilove11ven: I'll install it and test [08:42] <ilove11ven> bencc: ffmpeg -codecs tells nellymorser should be supported. [08:44] <bencc> trying [08:45] <ilove11ven> bencc: I have published stream to adobe's server using FFmpeg, but failed to do so, since a command FFmpeg is sending is not supported on the server side. Commenting it out solves the problem. You case might be similar. [08:45] <bencc> what command is failing? [08:46] <ilove11ven> half a year ago. Let me check the code. [08:47] <bencc> ilove11ven: I see nellymoser in ffmpeg -codecs [08:47] <ilove11ven> yes. That suppose to work, but i have not tried it. [08:48] <bencc> http://dpaste.com/1270087/ [08:49] <bencc> this is what I'm getting [08:49] <bencc> Proto = rtmp, path = /oflaDemo/test, app = oflaDemo, fname = test [08:50] <bencc> what "fname = test" means? [08:51] <bencc> ilove11ven: what syntax do you use? [08:51] <ilove11ven> file name. That's explained in RTMP spec [08:51] <bencc> I don't have filename [08:52] <bencc> I only have app (oflaDemo) and stream (test) [08:54] <steinchen> or should i use x/60 ? [09:06] <ilove11ven> bencc: ffmpeg -i rtmp://192.168.42.19:1935/vod/mp4:sample2_1000kbps -f mp4 -vcodec copy /dev/null [09:06] <ilove11ven> bencc: just setup fms, which has not been used for months. huuuu [09:08] <ilove11ven> bencc: I expect a wireshark capture will reveal which command failed, then we know what to do next. [09:53] <RSDRSDRSD> why does ffmpeg -y -i šrtmp://5.178.66.238:80/sexdumpertlive/sexdumpert/channel1 stop=1 live=1š give an error and without š it is working [09:57] <RSDRSDRSD> what is the best method to get screenshots of a live rtmp stream [09:57] <RSDRSDRSD> can find a working solution [09:57] <RSDRSDRSD> canŽt [10:08] <steinchen> how may i take a screenshot every 3 seconds? [10:11] <saste> steinchen, select=gte(t, selected_n*3) [10:44] <esperegu> Hi. I want to stream my desktop audio over rtsp but I get a high cpu load (around 27). I have the following commandline: [[[ffmpeg -vn -f alsa -i pulse -acodec libvo_aacenc -ar 16000 -ac 1 -b 28000 -f rtsp -metadata title=desktop http://localhost:554/flvplayback ]]]. when I run vlc like this [[[ cvlc -vvv pulse://alsa_output.pci-0000_00_1b.0.analog-stereo.monitor --sout '#transcode{acodec=mp4a,ab=22,channels=1}:rtp{sdp=rtsp://0. [10:44] <esperegu> 0.0.0:8080/test.sdp}' ]]] the load is only about 2. Anyone knows how to solve this high load for ffmpeg? [12:20] <superware> vlc udp://@:1234 works while ffplay udp://127.0.0.1:1234 shows nothing but lots of errors such as "fPES packet size mismatch" etc, any ideas? [12:32] <superware> anyone? :| [12:41] <superware> Mavrik: hi [13:14] <esperegu> FYI: [13:14] <esperegu> $ git clone --depth 1 git://source.ffmpeg.org/ffmpeg [13:14] <esperegu> Cloning into 'ffmpeg'... [13:14] <esperegu> fatal: read error: Connection reset by peer [13:17] <saste> esperegu, git is dow [13:17] <saste> *down [13:17] <esperegu> saste: I saw that. didn't know if that was known ;-) [13:54] <superware> Mavrik? [14:28] <JustinInTheFlesh> Anyone familiar with stream via rtp from a direct show device? [15:31] <superwar> Mavrik? [15:33] <sacarasc> There's no one by that nick in the channel. [15:46] <jure> is this still true? http://transcoding.wordpress.com/2011/11/16/careful-with-audio-resampling-u… [15:49] <ubitux> the defaults changed [15:49] <ubitux> so it should not be the case [15:50] <jure> does it use ssrc now? [15:50] <ubitux> no, we improved the defaults [15:52] <ubitux> there is a way to use sox resampler though [15:58] <superware> "vlc.exe udp://@:1234" works while "ffplay udp://127.0.0.1:1234" shows nothing but lots of errors such as "fPES packet size mismatch" etc, any ideas? [16:08] <superware> Mavrik: hi, you here? [16:15] <superware> I have a H.264 TS over UDP, "vlc.exe udp://@:1234" works while "ffplay udp://127.0.0.1:1234" shows nothing but lots of errors such as "fPES packet size mismatch" etc, any ideas? [16:48] <bencc> I'm able to get mp3 file from a live rtmp stream: ./ffmpeg -i rtmp://127.0.0.1/audio/test -rtmp_live 1 -ar 44100 -f mp3 test.mp3 [16:48] <bencc> when replacing test.mp3 with pipe:1 I'm exepcting to get the stream in real time [16:49] <bencc> but I only see the output when the rtmp stream ends [16:51] <klaxa> bencc: why are you using pipe:1 ? [16:51] <klaxa> and not pipe: or pipe:0? [16:53] <bencc> klaxa: isn't pipe:0 for stdin and pipe:1 for stdout? [16:54] <klaxa> uh... [16:54] <klaxa> nvm me then, lol [16:54] <bencc> I'm getting the same issue with avconv [16:54] <bencc> so ffmpeg doesn't know that the stream is live in real time [16:54] <bencc> I've tried "rtmp_live 1" but I'm not sure how to use it [17:03] <JuxTApose> hey guys, I am a blender developer and I am looking to improve our game engine ffmpeg video caching routine... [17:03] <JuxTApose> any suggestions on some good code examples? [17:06] <Mavrik> what do you mean by video caching? [17:07] <JuxTApose> mavrik let me get the source code page...on the game engine you can cache aka prefetch video to be played... [17:08] <JuxTApose> the issue to fix is the cache is dumped on looping and it creates a seconds versus frames issues that makes the loops skip frames... [17:08] <JuxTApose> it counts seconds then dumps the cache before all the frames have been played then it starts the playback from beginning to create the loop [17:08] <beginner> hi everybody, im having trouble with -t parameter. When im recording audio, the FFMPEG seems to ignore this parameter. What am I doing wrong? "ffmpeg -t 3 -f dshow -i audio="Mikrofon (Conexant SmartAudio H" -f dshow -i audio="virtual-audio-capturer" -y -f flv test.flv [17:09] <Mavrik> beginner, put it after "-i" for starters :) [17:09] <JuxTApose> let me look at the code and get you some line numbers, it's pretty simple yet creates the bad skip side effect in seamless loops... [17:10] <JuxTApose> the operative word here is "seamless" [17:10] <JuxTApose> such as an ocean wave loop [17:11] <beginner> oh yea it worked thanks. I thought the order of the parameters are not taken into account [17:14] <Mavrik> beginner, ffmpeg is rather strict when it comes to parameter order [17:15] <Mavrik> ffmpeg <parameters applied to input> -i .. <parameters applied to 1st output> file.mp4 <parameters applied to 2nd output> file2.mp4 ... [17:17] <beginner> I see [17:19] <Mavrik> JuxTApose, sorry, but it's not really clear what your usecase and problem is or just how are you using ffmpeg [17:20] <JuxTApose> I am looking at the source code to find the routine...I'm away from my normal dev computer so it's taking me a minute... [17:21] <JuxTApose> essentially the user case is that seamless animation looping as in a loop that have ending and beginning frame aligned to create a continual loop without misalignment of motion [17:22] <JuxTApose> in the file that is using ffmpeg to playback that loops it is evaluating seconds instead of frames to end the loop...any frames that are a fraction of a second on the end of the animation are not played because the cache is purged on a even second count... [17:23] <JuxTApose> so a seamless animation of 5 seconds and 10 frames is looped at the 5 second mark, not the 5 second + 10 frames mark... [17:23] <JuxTApose> so I am looking for some source code examples that properly handling ffmpeg video playback caching... [17:24] <JuxTApose> i'm looking back at the source code now, the routine obviously shows this issue... [17:28] <Mavrik> uh ok [17:29] <Mavrik> you're calling out to the ffmpeg executable or are you linking against libav libraries_ [17:31] <JuxTApose> linking for those still here.... [17:31] <JuxTApose> http://www.letworyinteractive.com/blendercode/d1/d9a/VideoFFmpeg_8cpp_sourc… [17:32] <JuxTApose> offending line I think is 768 [17:33] <JuxTApose> it dumps the cache and starts playback via a seconds reference not an actual frame count reference if the source is seconds plus a fraction of a second in playback... [17:33] <JuxTApose> normal video it will not be noticed only in seamless animation loops will this be noticable [17:48] <JuxTApose> wb Mavrik [17:49] <JuxTApose> blender links to the libraries [17:49] <JuxTApose> the offending line looks like #768 in http://www.letworyinteractive.com/blendercode/d1/d9a/VideoFFmpeg_8cpp_sourc… [17:50] <JuxTApose> the test true dumps the cache and starts playback via a seconds reference not an actual frame count reference if the source is seconds plus a fraction of a second in playback... [17:50] <JuxTApose> normal video it will not be noticed only in seamless animation loops will this be noticable [17:53] <sobaah> hi all [17:53] <JuxTApose> Ok, so what's the question again? Can anyone link me to some source code that efficiently handles video playback caching at the frame level from the ffmpeg linked libraries? [17:55] <sobaah> having a small issue with trying to sync an mp3 from an mp3 recorder and a video from a DV camera that output in mpg format. [17:55] <sobaah> Camera: [17:55] <sobaah> Video framerate: 59.940059, original audio sample rate: 48000kHz [17:55] <sobaah> MP3 recorder: audio sample rate: 44100kHz [17:56] <sobaah> Issue is that the video is 6.5hours long and by the end of the video, the audio is out of sync by 1.3seconds [17:56] <jure> JuxTApose: why are you not in #ffmpeg-devel ? [17:57] <sobaah> can anybody let me know how to fix this? I've tried changing the sample rate and using other CLI utilities to change the speed but it's not working well [17:57] <JuxTApose> O.o cuz I didn't know it existed....i found this on a search..I'm headed there now, thanks jure [17:58] <ubitux> that's the correct channel [17:58] <ubitux> to ask for API [17:58] <ubitux> API usage* [17:58] <ubitux> (#ffmpeg) [18:00] <sobaah> does anyone know of a channel that might deal with these issues? please [18:02] <brontosaurusrex> sobaah, audio is longer? [18:03] <sobaah> hey brontosaurusrex, yes the audio seems to be a bit longer [18:03] <sobaah> I have to apply a speedup of 1300ms for it to sync [18:03] <brontosaurusrex> ok, then align the two in your favorite editing app [18:03] <brontosaurusrex> and play until its visible out of sync [18:03] <sobaah> is there a common issue I am not seeing though? [18:03] <brontosaurusrex> then just cut out the audio until it fits [18:03] <sobaah> the issue is actually not just in the length [18:04] <sobaah> it's that the audio is playing slower [18:04] <brontosaurusrex> sobaah, probably dv capturing is missing a frame or two? [18:04] <sobaah> hmm, I see [18:04] <sobaah> the sample rates are different from the original video file, 48000 vs the one in the mp3, 44100 [18:04] <brontosaurusrex> also the devices may run at slightly different speeds [18:05] <sobaah> hmm, is this an issue that I could research? I mean...like the common playback speed differences in PAL vs NTSC, etc [18:05] <brontosaurusrex> well, sample rate is usually choosen depending on your final format needs [18:05] <sobaah> the difference I am seeing is unlike any ratio I've ever seen [18:06] <sobaah> hmm, I see bron [18:06] <sobaah> err [18:06] <brontosaurusrex> thats not pal vs ntsc issue [18:06] <sobaah> brontosaurusrex [18:06] <sobaah> right, I underatand [18:06] <sobaah> I was just asking if there is some sort of known issue that I can look into [18:06] <sobaah> similar to that [18:07] <sobaah> because at this point I'm just doing it "by ear", it sync near the end of the 6.5h video with a 1300ms negative delay [18:07] <brontosaurusrex> you did hear the pro devices are usually locked by some sort of signal right? [18:07] <sobaah> it syncs up near* [18:07] <sobaah> but at the beginning, the video and audio are pretty well synced [18:07] <sobaah> or at least not off by 1.3s! [18:07] <sobaah> =D [18:07] <sobaah> hmm, brontosaurusrex, locked how? [18:07] <jure> https://kb.speeddemosarchive.com/Progressive_Audio_Desync [18:08] <brontosaurusrex> a generator of some sort [18:08] <brontosaurusrex> used to be a called house-sync or black-burst [18:08] <sobaah> hmm, we're just using a regular digital camera and an mp3 recorder [18:08] <sobaah> for some training [18:08] <brontosaurusrex> yeah, that should work well, unless your clips are 7 hours long [18:09] <sobaah> heh, indeed, brontosaurusrex [18:09] <sobaah> thanks, jure [18:10] <jure> their solution is a bit too complicated though [18:10] <sobaah> seems like that is a defined concept of what I am seeing/hearing [18:10] <sobaah> Ive done more complicated things =D [18:10] <jure> unnecessarily complicated [18:10] <sobaah> ffmpeg is amazing, but it's a bit iffy at changing speed of audio [18:11] <sobaah> hmm, what would you suggest? [18:11] <sobaah> using setpts? [18:11] <jure> virtualdub has a nice feature to force audio/video sync [18:11] <sobaah> yep, seen that also [18:11] <sobaah> thing is I dont want to have to reencode [18:11] <sobaah> I just want to fix the audio file itself [18:11] <sobaah> then merge it with the video file [18:11] <jure> then open the video file in audacity, it will auto-strip the audio out of it [18:11] <sobaah> hmm, I guess VirtualDub should met me do it [18:12] <sobaah> met=let [18:12] <sobaah> dont have audacity =. [18:12] <sobaah> =/ [18:12] <sobaah> is it free? [18:12] <jure> yes [18:12] <sobaah> I forget [18:12] <sobaah> ahh, I see [18:12] <sobaah> I can strip the audio using ffmpeg too [18:12] <brontosaurusrex> sobaah, avisynth? [18:12] <sobaah> I have the video file and the mp3 from the recorder [18:12] <sobaah> I just want to fix the audio to the correct length [18:12] <jure> you can then either resample or change the audio speed in audacity [18:13] <sobaah> mmm have never tried avisynth, brontosaurusrex, Ive heard of it though [18:13] <sobaah> mm, ok jure [18:13] <brontosaurusrex> sobaah, basically: [18:13] <sobaah> I tried a resample in ffmpeg but it didnt make much of a difference [18:13] <jure> then you save that file and remux with ffmpeg [18:13] <sobaah> sounds good jure [18:13] <sobaah> I figured I would need to do so [18:13] <brontosaurusrex> v=video.avi, a=audio.wav, resample(a)ToFixLenght, resample(a)to48kOr something, dub(v,a) [18:14] <sobaah> o right avisynth is pretty much a scripting language? [18:14] <brontosaurusrex> but you will need to reencode [18:14] <brontosaurusrex> yes [18:14] <sobaah> and it ties in with VD [18:14] <brontosaurusrex> yes [18:14] <sobaah> yeah, never tried it but sounds cool [18:14] <sobaah> jure, was more just wondering, initially, if there was something simple I was missing [18:14] <jure> well, yeah, there is [18:15] <sobaah> heh [18:15] <sobaah> the PAD? [18:15] <sobaah> Progressive Audio Delay? [18:15] <jure> desync [18:15] <sobaah> DeSync* [18:15] <sobaah> heh yah [18:15] <sobaah> that? [18:15] <jure> no [18:15] <sobaah> or was it something else? [18:15] <sobaah> oh [18:15] <jure> sample rate difference causes it [18:16] <sobaah> thanks for the help, brontosaurusrex [18:16] <sobaah> hmm, I figured as much [18:16] <sobaah> 48000 vs 44100 [18:16] <jure> those 4000 samples get piled up eventually [18:16] <sobaah> but Ive changed it using both eac3to and ffmpeg [18:16] <sobaah> and still, it didnt seem to affect the delay [18:17] <sobaah> can I resample the mp3 directly or would it be preferable to change it to a different format? [18:17] <brontosaurusrex> samplerate shouldn't make a difference [18:17] <jure> transcoding loses fidelity [18:17] <sobaah> I converted the mp3 to an ac3 using ffmpeg, but when playing the ac3 in VLC, the total runtime jumps around like it's trying to be calculated [18:18] <sobaah> right, I understand about the loss during compression/transcoding [18:18] <sobaah> but I'm just trying to get it to work firsty [18:18] <sobaah> first* [18:18] <jure> probably bad container format [18:18] <sobaah> brontosaurusrex: hmm, you think the sample rate shouldnt make a diff? [18:18] <jure> (total runtime jumping around) [18:18] <sobaah> mm, I see jure [18:18] <jure> I don't know why you'd convert mp3 to ac3 though [18:19] <sobaah> it was to try to let eac3to change the sample rate [18:19] <sobaah> the documentation says it works with "any format" [18:19] <brontosaurusrex> sobaah, if i fart 3 times per second or 100 times per second, its still just a second [18:19] <jure> sure, that's why you had to transcode it from mp3 right? [18:19] <sobaah> but I've tried various mp3s and it just ignores all options for doing stuff [18:19] <sobaah> yep, jure [18:22] <jure> *sigh* [18:22] <sobaah> brontosaurusrex: I agree but I believe sample rate still has something to do with it [18:22] <brontosaurusrex> how? [18:22] <sobaah> also, a bit vulgar choice of an example [18:22] <sobaah> im not sure atm but I found a few threads pointing to changing sample rate in Audacity to fix audio sync issues [18:22] <sobaah> i'll give audacity a go, thanks both of you, jure and brontosaurusrex [18:22] <jure> fiddling around with sample rate to fix audio sync is tricky, just so you know [18:23] <sobaah> jure, hmm [18:23] <sobaah> so just change tempo instead? [18:23] <sobaah> or what should I go for? [18:23] <jure> you should play around with audacity for a while, see what you can do [18:24] <sobaah> but with the sample rate right? [18:24] <jure> but work on a smaller patch of the video, not the entire 6 hours [18:24] <sobaah> it's hard not to work with the full length [18:24] <sobaah> simply because the audio becomes desynced near the end [18:24] <sobaah> or at least that's where I see it more noticeably [18:24] <brontosaurusrex> sobaah, http://avisynth.nl/index.php/FPS , see PAL +4% conversion example [18:24] <sobaah> 1300ms difference [18:25] <brontosaurusrex> its basically dual-resampling [18:25] <brontosaurusrex> but as allready mentioned your sync may not be gradually and linearly lost, but missing frames on places [18:25] <brontosaurusrex> + unknown [18:26] <sobaah> hmm [18:26] <sobaah> going to go check if near the middle of video [18:26] <sobaah> there is a 1300/2 difference [18:26] <sobaah> should have done that [18:26] <brontosaurusrex> yes [18:27] <sobaah> actually, I realized... [18:27] <sobaah> this camera writes oddly [18:27] <sobaah> it can only have 2Gb of data before it creates a new file within the camera [18:27] <sobaah> probably due to memory or file cluster reasons [18:28] <jure> maybe the file can't be larger than 2GB [18:28] <sobaah> right, due to the reasons above [18:28] <jure> fat16? [18:28] <brontosaurusrex> maybe the drives are formated to fat32 or something [18:28] <sobaah> I think, perhaps, when it's finalizing one file and starting the next one, it loses some frames there [18:28] <jure> yeah, fat32 [18:28] <sobaah> that's what I was thinking too [18:28] <sobaah> file cluster reasons [18:29] <brontosaurusrex> nah, i did a lot of video with a sony camera like that, never missed a frame [18:29] <sobaah> when I export the file out, the program merges the files and outputs them into an .mpg container [18:29] <Mavrik> uh [18:29] <sobaah> mm, yep, this is a SONY camera [18:29] <Mavrik> do you have a camera that records into AVCHD? [18:29] <sobaah> it's an older camera, Mavrik [18:29] <Mavrik> (sorry, came slightly late) [18:29] <sobaah> so prob not AVCHD [18:29] <sobaah> heh, np always appreciate any help [18:30] <sobaah> im just having some desync issues [18:30] <Mavrik> anyway, I had problem with Sony cameras which recorded into AVCHD which was also split into 2GB chunks [18:30] <sobaah> 6.5hour long video has a 1300ms difference between it and an mp3 recorder that we used at the same time [18:30] <Mavrik> and merging it with anything that wasn't proprietary Sony software caused some video frames to be lost on file boundaries [18:30] <sobaah> this is SONY's PMB software though [18:30] <sobaah> I'm not doing it on my own [18:31] <sobaah> though I would if needed [18:31] <sobaah> it automatically exports the 2GB files and puts them all together [18:31] <sobaah> into 1 large 15GB file (for this particular vid) [18:31] <sobaah> lunch [18:31] <sobaah> thanks everyone! [21:19] <z_sat> I'm trying to set up some options for a AVCodecContext using AV_CODEC_ID_H264 and I can't seem to find av_opt_set function. Is that fcn avail in V1.2 or has it been replaced? [21:31] <superware> this is what I get when trying to ffplay an h.264-ts-udp stream http://pastebin.com/bFUvBwHU which actually plays nicely with VLC... any ideas? [22:09] <nwave> is it possible to take an rtsp stream and store it to disk in 5 second segments with the timestamp of the file as the name of the segment file? [22:14] <saste_> nwave, not yet, but check the segment muxer [22:17] <nwave> so can I do http live streaming HLS with ffmpeg, like I can with VLC? [22:18] <saste_> HLS braindead streaming? yes [22:18] <JEEB> ffmpeg can do the HLS part of it, and then you will have to have a server serving those files it made [22:19] <nwave> cool. are there any examples or some documentation on that? [22:19] <saste_> nwave, segment, hls muxers in man ffmpeg-formats [22:19] <JEEB> and just output to a directory that is then shared by a http server [22:19] <JEEB> s/shared/served/ [22:19] <sobaah> saste_: man, what did you write there? [22:19] <sobaah> =P [22:19] <sobaah> I am a tech geek but wth? [22:24] <sobaah> oh, thought that said "his muxiers" [22:24] <sobaah> was like...what? [22:24] <sobaah> xD [22:24] <sobaah> muxers* [22:25] <nwave> is mlaw audio not able to be encapsulated in mp4? [22:25] <JEEB> no [22:25] <saste_> nwave, from what i know no raw audio (mlaw counts more or less as raw audio) [22:26] <nwave> interesting [22:26] <JEEB> yeah [22:26] <JEEB> raw audio is only being added to 14496-12 IIRC [22:26] <JEEB> if only itscj.ipsj.or.jp was alive [22:26] <JEEB> has been dead for a week now [22:26] <JEEB> could've checked [22:26] <nwave> so is there a way I can take this rtsp stream I have that has h264 video and mlaw audio and dump it to an mp4 file and encode the audio in an acceptable format? [22:27] <JEEB> sure, if you re-encode it into a format that fits then all's fine [22:28] <nwave> is AAC a normal audio format for mp4? [22:30] <JEEB> fits just fine, yes [22:31] <nwave> should this work.... ffmpeg -i out.avi -c:v copy -c:a libfdk_aac -vbr 3 out.mp4 [22:32] <JEEB> not sure what the vbr option is, but if you set some kind of rate control mode and -afterburner 1 it should be fine, yes [22:34] <nwave> http://pastebin.com/PxwjSbze [22:34] <nwave> not sure what's it complaining about [22:36] <JEEB> libfaac doesn't support this output format! [22:36] <JEEB> is the actual error [22:36] <LithosLaptop> try libmp3lame [22:36] <JEEB> basically it's most probably the sample rate [22:36] <LithosLaptop> should give better quality than libfaac and also fits in mp4 container [22:36] <axorb> hey guys, I'm trying to segment a video, but it's not working for one of my test files: http://pastebin.com/2f3FEsCh [22:37] <JEEB> yeah, but if we go there he might as well use fdk-aac [22:37] <LithosLaptop> yes [22:37] <JEEB> of course he'd have to compile it first, though [22:37] <axorb> [nut @ 0x1b17380] Negative pts not supported stream 0, pts -9223372036854775808 [22:37] <nwave> track 1: muxing mp3 at 8000hz is not supported [22:37] <LithosLaptop> oops [22:37] <LithosLaptop> you could resamle first [22:37] <LithosLaptop> resample [22:38] <nwave> how do I do that [22:38] <LithosLaptop> -ar [22:38] <LithosLaptop> -ar 11025 [22:38] <LithosLaptop> I don't know what sample rates are supported [22:39] <LithosLaptop> think 22050 should work [22:41] <nwave> ffmpeg -i out.avi -c:v copy -c:a libmp3lame -ar 22050 -b:a 128k out.mp4 [22:41] <nwave> this created the file fine, but I don't hear audio [22:43] <superware> I have an h264-ts-udp stream being played by VLC --demux ffmpeg udp://@:1234 but not by ffplay udp://127.0.0.1:1234 (log at http://pastebin.com/bFUvBwHU) [22:43] <llogan> nwave: in what player? [22:48] <superware> a better log: http://pastebin.com/4navfRNM [22:49] <superware> only on line 383 it detects the stream #0:0, not still no video [22:58] <nwave> how can I get ffmpeg to be an rtmp server [22:58] <nwave> translate a rtsp stream to rtmp? [23:02] <ThePendulum> Greetings [23:03] <nwave> llogan: sorry, didn't see you were addressing me. I figured it out needed to use sample rate 44100 [23:07] <nwave> I'm tryingto set up a HLS segmenting from an RTSP stream but I keep getting this error [23:07] <nwave> cmd: ffmpeg -i "rtsp://10.2.2.20:81" -c:v copy -c:a libmp3lame -ar 44100 -f segment -segment_list out.list -segment_time 2 -segment_wrap 20 hls5.mp4 [23:07] <nwave> error Output file #0 does not contain any stream [23:42] <superware> how should I ffplay a h264-ts-udp stream? [23:50] <superware> I guess probing is quite poor for my network stream [00:00] --- Wed Jun 26 2013

1 0