Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
August 2014
- 1 participants
- 60 discussions
[02:12] <cone-989> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:d67d4072390d: ffserver: tests, use new port/bindaddress config
[02:12] <cone-989> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:07bc24973b8c: ffserver: tests, use Metadata title in config
[02:29] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:30f680ee0a27: avcodec/vc1dec: fix null pointer dereference
[03:05] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:a2841d92c384: Revert "pnmenc: use bits_per_raw_sample"
[12:25] <cone-798> ffmpeg.git 03Anton Khirnov 07master:6ca11f7157d0: doc/APIchanges: fill in missing hashes and dates
[12:25] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:f1b04f803eaf: Merge commit '6ca11f7157d0ffd11ea9a4211b04981b46dc75d6'
[12:35] <J_Darnley> ubitux: I've just seen your message from yesterday...
[12:37] <J_Darnley> It works fairly well for detecting which "video frame" should be a beat
[12:37] <J_Darnley> or should sow a beat.
[12:37] <J_Darnley> *show
[12:38] <J_Darnley> I have no idea how it works though
[12:38] <J_Darnley> It was and still is a lot of messy code.
[12:40] <J_Darnley> I haven't tried cleaning it up yet.
[12:40] <J_Darnley> I could spin it off into some skeleton of a filter so you can see it on its own.
[13:27] <cone-798> ffmpeg.git 03Anton Khirnov 07master:b263f8ffe759: lavf: add AVFormatContext.max_ts_probe
[13:27] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:215db2935b06: Merge commit 'b263f8ffe7599d9cd27ec477a12700da8eb2790d'
[13:33] <cone-798> ffmpeg.git 03Rémi Denis-Courmont 07master:6ee1cb5740e7: libavformat: use MSG_NOSIGNAL when applicable
[13:33] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:08a110ca871e: Merge commit '6ee1cb5740e7490151db7dcec7e20ceaf8a2fe1f'
[15:14] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:d647ef0c8069: avcodec/mpegvideo_parser: consider vbv_delay in bitrate heuristic also for mpeg2
[15:59] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:beaf86bd02e4: doc/APIchanges: fill in dates and hashes
[16:13] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:52fca28c3bf5: avcodec/vorbisenc: use av_malloc(z)_array()
[16:13] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:bb29896793bf: avutil/opencl: use av_malloc(z)_array()
[17:25] <wm4> so, many files have stuff in AVFormatContext.metadata which are not file tags at all, e.g. mp4 has crap like "compatible_brands"
[17:25] <wm4> do we need a way to separate real tags from additional metadata?
[17:26] <wm4> any suggestions? maybe a separate tags dict?
[17:35] <ubitux> wm4: add a special flag/category to AVDictionaryEntry?
[17:35] <ubitux> theree are a bunch of metadata with special meaning
[17:35] <nevcairiel> That seems like a better solution than a separate dict
[17:35] <ubitux> i can think of the mp4 stuff typically, or timecodes, or even lavfi frame metadata
[17:36] <ubitux> typically you don't want to store a "rotate" tag when converting from mp4 to mkv
[17:36] <ubitux> nor you would be interested in lavfi.xxx tags
[17:37] <ubitux> i would support such changes
[17:38] <wm4> I don't know, dict entries don't have flags yet, so that'd be weird
[17:38] <wm4> "lavfi.xxx tags"?
[17:39] <wm4> also, there was at least one user who was interested in "untranslated" tag names (lavf tries to rename format specific tags to generic names)
[17:49] <nevcairiel> wm4: BTW, NVIDIA has a special OpenGL extension for DX interop, but of course its NV specific and still marked experimental, despite being years old already
[17:49] <wm4> as expected
[17:49] <nevcairiel> http://developer.download.nvidia.com/opengl/specs/WGL_NV_DX_interop.txt
[17:51] <wm4> probably not generally useable (might be unstable, and is extra work since it won't work with other drivers)
[17:52] <nevcairiel> I'll never need it, but it's interesting non the less
[18:00] <ubitux> wm4: lavfi.xxx tags are AVFrame tags, they're not remuxed currently anyway
[18:00] <ubitux> but it could be better than this "lavfi." prefix
[18:01] <wm4> why not make tags side data!
[18:02] <ubitux> lol
[18:02] <nevcairiel> Well they kinda are anyway
[18:09] <durandal_1707> this: http://git.1f0.de/gitweb?p=ffmpeg.git;a=commit;h=b7c37a5541b8bf69ba173ad726…
[19:09] <cone-798> ffmpeg.git 03Vignesh Venkatasubramanian 07master:080acf7771e1: lavf/matroskadec: Ensure cues_end is initialized
[19:20] <kierank> ubitux: when is ffmpeg chocolate coming
[19:21] <kierank> libav have chocolate
[19:21] <kierank> and i thought the idea is to have ffmpeg a strict superset of libav
[19:22] <ubitux> i wouldn't mind not having food, trains & travel discussions all the time here :)
[19:22] <ubitux> i'm not into this commercial thing, ask someone else if you want such thing
[19:24] <Daemon404> kierank, bake a cake with libav chocolate
[19:24] <Daemon404> bam. superset.
[19:24] <kierank> i have started making zero noodles my food of choice
[19:24] <kierank> https://www.boots.com/en/Zero-Noodles-Original-200g_1469881/
[19:25] <kierank> bought the entire stock of bristol today
[19:25] <Daemon404> oic
[19:25] <Daemon404> i (we) only buy noodles from hong kong / china from the asian supermarket
[19:25] <Daemon404> and/or japan
[19:25] Action: Daemon404 has no choice in the matter
[19:25] <kierank> that packet of noodles is FOUR calories
[19:26] <wm4> huh, why would people buy food with no nutritional value...
[19:26] <kierank> as a base for food with nutritional value
[19:27] <Daemon404> ive mostly been cooking healthyish food lately
[19:27] <Daemon404> *mostly*
[19:44] <rcombs> so, I've been in an email chain with our CEO and a copyright and licensing lawyer
[19:44] <rcombs> and he believes that FDKAAC's license is GPL-compatible, because the patent licensing section is not part of the license, but instead a separate advisory
[19:45] <rcombs> so, that means that FDKAAC shouldn't have to be considered non-free
[19:46] <rcombs> if anyone would like details or to speak to him directly, feel free to PM or email me
[19:46] <j-b> https://github.com/mstorsjo/fdk-aac/blob/master/NOTICE
[19:46] <j-b> this is the license
[19:46] <j-b> "Software License for The Fraunhofer FDK AAC Codec Library for Android"
[19:47] <j-b> the whole file
[19:47] <j-b> not just one part
[19:47] <j-b> section 4 is the usual "No warranty clause"
[19:47] <j-b> and is found in all the FLOSS licences
[19:48] <rcombs> 'I see no issue under GPL here. The reference to patent licenses is advisory and not a limitation on use. In essence, it says, "you can get a license here if you want one [implicitly, if you don't, you are at your peril], but you may not need one because most Android hardware makers already have one that covers you."'
[19:48] <j-b> "You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized
[19:48] <j-b> by appropriate patent licenses."
[19:48] <j-b> "You may use .. only .."
[19:49] <j-b> [implicitly, if you don't, you are not allowed to use]
[19:50] <kierank> rcombs: the requirement to have a patent licence is an additional restriction under the gpl
[19:50] <rcombs> I'll get back to Chris with a copy of this conversation
[19:51] <j-b> I agree with kierank (as usual)
[19:52] <wm4> "It is patented but free to use as long as you use the openexr library."
[19:52] <wm4> what the shit
[19:52] <wm4> (OpenEXR)
[19:52] <JEEB> lol
[19:53] <Daemon404> for troll purposes, i should remind you guys i contacted the SFLC
[19:53] <Daemon404> and they said not-GPL-compatible
[19:53] <j-b> Daemon404: can you fwd the email?
[19:53] <j-b> please?
[19:53] <Daemon404> j-b, it is ages old, but i can find and fwd it to you
[19:53] <Daemon404> which email?
[19:53] <rcombs> Daemon404: also to me? at rodger(a)plexapp.com
[19:53] <Daemon404> jb(a)v.o?
[19:53] <j-b> Daemon404: yes
[19:53] <j-b> ah, you're from plex...
[19:54] <Daemon404> rcombs, ok.
[19:54] <j-b> that explains a lot...
[19:54] <wm4> trollol
[19:54] <Daemon404> j-b / rcombs -- are you OK with a bunch of .eml attachments for teh thread
[19:54] <Daemon404> its how tbird does it.
[19:54] <wm4> j-b: well he was a free open source spirit until recently
[19:54] <rcombs> Daemon404: sure
[19:54] <rcombs> this started because I asked our CEO to talk to Fraunhofer about relicensing FDKAAC under something GPL-compatible
[19:55] <Daemon404> gl;hf
[19:55] <rcombs> and he said he'd double-check with a licensing attorney about whether or not the existing license was compatible first
[19:55] <Daemon404> hmm which email addy did i use...
[19:55] <rcombs> which made me :rolleyes:, but figured it couldn't hurt
[19:56] <rcombs> so, I've told him your reply now (which I agree seems accurate, but I'm not a lawyer), and he'll either try to convince everyone you're wrong, or agree and then we'll go to Fraunhofer with money
[19:57] <wm4> isn't that what they want, Money
[19:57] <wm4> just use the lavc encoder
[19:57] <wm4> not like your users hear the difference
[19:57] <wm4> or why use aac at all
[19:57] <rcombs> wm4: we'd like fixed-point for some platforms
[19:57] <Daemon404> aha found it
[20:00] <Daemon404> j-b / rcombs - sent
[20:01] <rcombs> j-b: for the record, I came onboard a few months ago, and am trying to get us to build better relations with ffmpeg than we've historically had
[20:01] <Daemon404> kudos
[20:02] <j-b> you mean, stop exploiting open source for money and give almost nothing back?
[20:03] <wm4> is plex closed source shit?
[20:04] <rcombs> wm4: media server is open-source; it uses ffmpeg shared libs (under LGPL) and a full compiled modified ffmpeg binary (under GPL), with the source for both published
[20:04] <wm4> that's nice
[20:05] <rcombs> and I'm intending to push any bug fix we make from here on to upstream, and possibly some new work; our CTO is hesitant because he's afraid of helping competitors, but I think we'd be much better off having a good relationship with ffmpeg
[20:05] <kierank> lol this "helping competitor" argument
[20:05] <rcombs> kierank: yeah :\
[20:05] <j-b> exactly what I meant with above
[20:06] <j-b> Let's use open source, but please don't give anything back...
[20:06] <rcombs> Daemon404: huh, they pointed at the no-license-fee clause
[20:13] <Daemon404> eh dont ask me
[20:13] <llogan> rcombs: what are some of the modifications?
[20:15] <rcombs> llogan: we have a hack that enables ffmpeg to render inline ASS subtitles, a limited MPEG-DASH muxer (based on smoothstreaming), and various little compatibility tweaks on both input and output
[20:16] <llogan> you mean like the ass filter to make hardsubs (but without the need for standalone ass file)?
[20:16] <rcombs> e.g. if analysis fails to determine a video pixel format, we guess YUV420p because that's very common, rather than leaving it NONE and having a guaranteed failure; if the MOV timescale is very large, we actually reduce it instead of just warning
[20:16] <rcombs> llogan: right
[20:18] <rcombs> our MKV muxer writes the duration from the source file before it starts rather than an EBML void, so players know an approximate duration while we're transcoding
[20:18] <rcombs> the code for all this is available as a .tgz (and I've been trying to convince our CTO to just make the git repo public, but he really doesn't want to :( )
[20:19] Action: Daemon404 has a utility to determine what git hash tarbal ldrops are based on
[20:19] <rcombs> there are a few other little tweaks all over the place, some of which are Plex-specific (e.g. we log to the server via HTTP calls and throttle ourselves if the server says to)
[20:19] <Daemon404> more or less you otpimize for diff -urN | wc -l
[20:19] <Daemon404> find smallest #
[20:19] <rcombs> and there's some other stuff not yet released (and therefore not yet public), which I can tell you about when we launch
[20:20] <Daemon404> rcombs, it seems very dumb to keep it locked ep
[20:20] <Daemon404> up
[20:20] <rcombs> Daemon404: agreed
[20:20] <Daemon404> existign stuff i mena
[20:20] <wm4> but the competition
[20:20] <rcombs> Daemon404: well, I had the pleasure of doing the same before I was hired; it's easier than that
[20:20] <rcombs> Daemon404: there's a RELEASE file (or whatever it's called) in the tarball, and it's forked off that exact tag
[20:21] <rcombs> superpea: 'ello
[20:21] <Daemon404> rcombs, not all source drops are forked off tags
[20:21] <Daemon404> ;)
[20:21] <superpea> hey rcombs!
[20:21] <rcombs> this is superpea, a coworker
[20:22] <JEEB> Daemon404, I remember making a similar tool once
[20:22] <JEEB> lörs lärä
[20:22] <llogan> rcombs: thanks for the descriptions. looking forward to your contributions.
[20:22] <wm4> Daemon404, j-b: if you want that nobody can "steal" ffmpeg without giving back, why not switch to AGPL3?
[20:22] <Daemon404> trolls gonna trol
[20:22] <Daemon404> l
[20:22] <rcombs> wm4: because re-licensing software this large with this many contributors is impractical
[20:22] <Daemon404> dont tell j-b that
[20:23] <Daemon404> because he did just that
[20:23] <Daemon404> relicensed all of libvlc.
[20:23] <Daemon404> (more or less)
[20:25] <j-b> wm4: no, but I really dislike Plex and their lack of commitment
[20:25] <j-b> they are mostly only a ffmpeg-rewrapper
[20:25] <j-b> and they refuse to share anything
[20:26] <j-b> or are plain rude
[20:26] <j-b> Daemon404: of course, the usual BS about relicesing
[20:26] <Daemon404> that said i think AGPL is crap
[20:27] <j-b> not to add that, in the US, relicensing is 10x easier, because of copyright vs authors rights
[20:27] <wm4> the GNU licenses would be nicer if they were properly interoperable with each others
[20:27] <nevcairiel> AGPL makes stuff finally entirely corporate incompatible
[20:27] <JEEB> just switches one corporate to another
[20:27] <JEEB> the FSF corporate
[20:28] <nevcairiel> Back when I still did web development, I stumbled across a few java libraries dual licensed AGPL and $$$
[20:28] <JEEB> yup
[20:28] <nevcairiel> If you use them you have to put info on your website
[20:28] <nevcairiel> Like any company is ever going to do thay
[20:28] <nevcairiel> that*
[20:28] <Daemon404> some do
[20:29] <Daemon404> e.g. http://www.whatsapp.com/opensource/
[20:29] <Daemon404> and they sold for 16 billion :P
[20:29] <nevcairiel> Not sure how it would really work out when you use it for internal purposes only
[20:29] <nevcairiel> I mean, not like anyone would ever find out anyway
[20:30] <nevcairiel> Stuff like WhatsApp sells for the user base, and absolutely nothing else. :P
[20:30] <Daemon404> yep.
[20:32] <nevcairiel> Speaking of aac earlier, someone wake that guy and his mega trac ticket up again
[20:32] <JEEB> zat german dude IIRC
[20:32] <JEEB> and yeah, we def. want that stuff merged
[20:33] <JEEB> there's so much code written and it has become better :s
[20:35] <Daemon404> "still worse than LAME"
[20:35] Action: Daemon404 runs
[20:36] <nevcairiel> I've had some noisy clips where the aac encoder really produces terrible artifacts, but its much better with the patch
[20:36] <nevcairiel> I should just apply it
[20:36] <Daemon404> what do you even want with it?
[20:36] <Daemon404> you write decoding filters
[20:37] <Daemon404> bitstreaming?
[20:37] <nevcairiel> For work
[20:37] <Daemon404> oh ok.
[20:37] <nevcairiel> We have a live transcoder for streaming to mobile
[20:37] <Daemon404> hmm, can you not link fdk directly to your software>
[20:38] <nevcairiel> Then I would have to implement a special encoding path
[20:38] <Daemon404> figured that was the answer
[20:39] <nevcairiel> This license thing is stupid. I could use it separately, but if I use it inside FFmpeg it goes all bad
[20:39] <nevcairiel> Do androids decode ac3
[20:40] Action: nevcairiel wonders
[20:40] <nevcairiel> It opus in ts? d:
[20:40] <nevcairiel> Hey kierank, going to build opus in ts mixing as well? :)
[20:40] <JEEB> ac3 is only supported if the maker got a license
[20:40] <nevcairiel> muxing*
[20:40] <JEEB> and used the dolby binary
[20:41] <kepstin-laptop> only very recent versions of android do opus in the media framework :/
[20:41] <kierank> nevcairiel: not until people ar ehappy with the spec
[20:41] <kierank> are
[20:41] <nevcairiel> so, 2018 then?
[20:42] <j-b> btw, do we know people good around libavcodec looking for a job > 50k¬ ?
[20:42] <nevcairiel> kepstin-laptop: might still be nice as an option
[20:47] <kierank> nevcairiel: the realistic answer is post-ibc
[20:47] <kierank> we can have a quick "is everyone happy session" at vdd
[20:49] <nevcairiel> I wouldn't really be able to use it in the next couple months anyway, I have a large project rewriting the whole encoding thing in the app lined up, but not immediately anyway
[20:50] <kierank> android doesn't support ac3 afaik
[20:50] <kierank> 7:37 PM <"Daemon404> hmm, can you not link fdk directly to your software> --> no it has a viral property
[20:50] <nevcairiel> And opus support would be a nice addition, if its viable by then (depending on support both in FFmpeg and Android)
[20:51] <kierank> vlc supports opus in android
[20:51] <kierank> I listen to it every day
[20:51] <j-b> opus > *
[20:51] <kierank> he-aacv2 is better
[20:51] <nevcairiel> We use the built-in media engine
[20:51] <kierank> but laaatency
[20:52] <nevcairiel> And the whole discussion started because we don't have a good aac encoder at hand, so.... ;)
[20:52] <kierank> use lame at 192kbps
[20:52] <kierank> i assume you have mp3 patents paid
[20:53] <nevcairiel> Can I shove that in a HLS TS stream?
[20:53] <kierank> oh surround sound and other stuff
[20:53] <kierank> yes
[20:53] <kierank> not sure if mp3 supports surround
[20:53] <nevcairiel> Stereo is fine for now
[20:54] <nevcairiel> Also, mp3 in ts is actually a thing? Don't think I've ever seen it
[20:54] <kierank> mp3 licensing for broadcast is expensive
[20:54] <kierank> afaik tat's why it's not used
[20:55] <nevcairiel> Android doesn't list it as a compatible combination, but who knows if it would be able to play that
[20:57] <kierank> apple says it is possible
[20:58] <nevcairiel> I shall just remember to try at some point
[20:59] <nevcairiel> With my usual luck, it works on nexus devices but fails on Samsung or Sony, like my last experiments with fragmented mov
[21:38] <Compn> Subject: WebM DASH Manifest Test Files
[21:38] <Compn> Size: 5677870 bytes
[21:38] <Compn> in moderation queue. 5mb email
[21:42] <wm4> wat
[21:44] <gnafu> Seems legit.
[21:46] <wm4> right now I only see a 11kb mail
[21:53] <Compn> i wasnt sure i should approve sending 5mb to the entire list
[21:58] <wm4> what was it?
[21:58] <wm4> surely not 5 MB of XML?
[21:59] <jamrial> dash_video1.webm and dash_audio1.webm judging by the second patch contents
[22:08] <llogan> Compn: i rejected it with a notificaiton to provide links to the files.
[22:17] <JayBlanc> The other channel has sent me here. My question is, is cli ffmpeg supposed to have positive return values when there have been recoverable errors in decoding/encoding? A glance at ffmpeg.c shows it's set by a global variable, which seems like a bad idea.
[22:19] <kepstin-laptop> JayBlanc: it's configurable with a command-line option
[22:19] <JayBlanc> Which is?
[22:19] <kepstin-laptop> (it annoyed me a bit that the default was changed from previous versions tho; it used to ignore them prior to 2.2)
[22:20] <JEEB> err_detect ? I couldn't find the IRC logs for whatever I looked into months before
[22:20] <JEEB> all of the settings are defined @ http://ffmpeg.org/ffmpeg-all.html
[22:21] <kepstin-laptop> -max_error_rate
[22:21] <kepstin-laptop> set it to 1.0 to make it ignore all errors
[22:22] <JayBlanc> And its undocumented.
[22:22] <JEEB> I would guess err_detect is actually the one you want if you want to set a specific level
[22:22] <JEEB> not sure what -max_error_rate is
[22:22] <JEEB> esp. since it's not in the documentation
[22:23] <kepstin-laptop> shows up with a description in `ffmpeg -h`, but yeah, the docs aren't very good :/
[22:23] <JayBlanc> err_detect is something entiely different.
[22:24] <JEEB> well looking at explode and ignore_err
[22:24] <JEEB> it can be used to either set ffmpeg to either ignore all errors or explode on any :P
[22:25] <JayBlanc> A better default for -max_error_rate would be something above 0.
[22:27] <JayBlanc> It's actually useful if it works the way I think it works, but it needed to be fully documented so people who write scripts that depend on the return value knew about it.
[22:27] <JEEB> uhh, looking at that help message it really seems like a rather vague thing :P
[22:27] <kepstin-laptop> after my scripts failed for no good reason when switching to ffmpeg 2.2, I had to go look it up in the git history to figure it out :/
[22:27] <JEEB> as in, it will ignore a certain amount of errors percentage-wise
[22:28] <JEEB> which doesn't seem very good for me :P
[22:29] <JEEB> I wish one of the maintainers was here because I'm most definitely not really good with the command line side of things due to mostly poking lavf/lavc and swscale
[22:29] <JEEB> because I just can't help but to feel that -max_error_rate is something very unspecific :P
[22:30] <JEEB> as in, will not help you if you only want to ignore errors of a certain level
[22:30] <JayBlanc> Yeah, I don't quite understand how errors get quantified into that percentage.
[22:30] <JEEB> they don't
[22:30] <JEEB> at least looking at the help
[22:31] <JayBlanc> Percentage of frames? Percentage of time? Percentage of unicorns?
[22:31] <JEEB> of all messages/return values I would guess, but looking at the source code is most probably more useful
[22:32] <kepstin-laptop> given how different codecs handle this differently, I don't think the percentage thing would be useful unless you have a really well defined use case
[22:34] <JayBlanc> This patch seems to have gone in very quickly too. Less than a weeks discussion on changing a fundemntal way the CLI functions.
[22:35] <JayBlanc> Or perhaps a failure to check that the function is only applied when directed to be applied.
[22:35] <JayBlanc> ie, it defaults to -max_error_rate=0 when it should be defaulting to -max_error_rate=1
[22:36] <JEEB> and yeah, it seems to be as vague as I thought :P http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=ffmpeg.c;h=d7bcb78cc0f7b…
[22:40] <JEEB> also the default is 2.0/3 , just fyi :P
[22:42] <JayBlanc> Well, then the functions is basically just broken, because it's triggering on things that I would not consider over two thirds 'errored'.
[22:43] <JEEB> also that's so arbitrary that I genuinely would be looking for other things like the stuff I noted if I some levels of errors are wished to be ignored. That said, not all decoders or demuxers differentiate between these
[22:43] <JayBlanc> Oh... Unless it sees 'corrections' in streams that are *meant* to be corrected for packet loss, ie over-the-air TS streams, as "Errors".
[22:44] <JayBlanc> In which case if could well be declaring perfectly decodable TS streams as "having too many errors".
[22:44] <JEEB> well it should be telling you the values if you enable debug output with -v debug
[22:44] <JEEB> "%"PRIu64" frames successfully decoded, %"PRIu64" decoding errors\n"
[22:44] <kepstin-laptop> I was seeing it trigger on some poorly-encoded flash svc2 streams that still decoded without any visible issues :/
[22:45] <JayBlanc> Yeah, I'm thinking about filing an error on it to get it pulled.
[22:45] <JEEB> I'm pretty sure the issue could rather be in the stuff being noted as errors rather than the amount of errors in general :P
[22:46] <JEEB> stuff like err_detect and verbosity or similar sounds like what could be useful, but at this point I think I'll just go throw myself at the bed
[22:47] <JEEB> also I consider both the old and the new behavior of how that thing worked goddamn arbitrary :P
[22:48] <JEEB> anyways, your issue is something being seen as an error rather than having a random % be too low/high.
[22:58] <JayBlanc> kepstin-laptop: Do you still have that flash stream to use as an example? The only files I have that are examples are too huge to upload as samples.
[22:58] <kepstin-laptop> I have several hundreds of gb of them, the trick is finding one that shows the issue and which isn't private :)
[22:59] <kepstin-laptop> but I'll take a look
[22:59] <kepstin-laptop> logs look like
[22:59] <kepstin-laptop> [flashsv2 @ 0x120cda0] 0x0 invalid color depth 3
[23:01] <kepstin-laptop> (these are made by custom java code in the bigbluebutton screen sharing app, so I'm not super-confident in the encoder quality :)
[23:54] <Timothy_Gu> Does FFmpeg accept patented but non-copyrighted code?
[23:54] <wm4> I think ffmpeg pretty much does not care about patents
[23:55] <wm4> it had native mp3 decoders at a time where distros patched many programs to remove mp3 decoders...
[23:56] <Timothy_Gu> And also on a completely unrelated topic, do you need to check errors for avio_tell()
[23:56] <Timothy_Gu> ?
[23:57] <Timothy_Gu> tell() uses seek(), which returns errors, but is there a way for this limited use of avio_seek() to actually fail?
[23:58] <wm4> hm
[23:58] <wm4> it calla avio_seek
[23:58] <wm4> *calls
[23:58] <wm4> and that can return AVERROR
[23:58] <wm4> sol I guess check if the result is <0
[23:58] <wm4> oh I'm blind
[23:58] <wm4> (and you too)
[23:58] <wm4> avio_tell documents: * @return position or AVERROR.
[00:00] --- Tue Aug 26 2014
1
0
[01:58] <djdduty> how can I make a timelapse video made with ffmpeg.exe -i %d.png -i song.mp4 -r 20 video.mp4 go longer than the song length?
[01:58] <djdduty> it keeps stopping the compilation at the length of the song rather than doing the entire thing.
[04:26] <Primer> How can one specify multiple input files with ffmpeg? Just multiple -i arguments?
[04:27] <Primer> I was hoping I could use a bash pattern, as I have several files...was hoping to not have to specify them all manually
[04:28] <Primer> seems that doesn't work anyhow
[04:29] <Hello71> !glob
[04:30] Action: Hello71 grumbles
[04:37] <Primer> I presume that's a hint to answer my question?
[04:37] <Primer> but the bot's not working?
[04:39] <Primer> I want to create a timelapse from several video files. I've been able to turn one video into a directory of images, then make a video of those images, but I have about 60 video source files
[04:39] <Primer> I was hoping to just batch that into one command line
[04:47] <Primer> nm, figured it out
[06:46] <benlieb> how do I change the scale of an mp4? I'm trying by -vf scale=WWW:HHH, where the dimensions give would in theory change the aspect ratio, but the aspect ratio doesn't change.
[06:55] <benlieb> anybody here?
[07:03] <cbsrobot-> benlieb: setdar=xxx/yyy
[07:04] <benlieb> every time I try this stuff I think i finally get it, but I don't.
[07:04] <benlieb> cbsrobot-: should I do that in addition to the scale -vf?
[07:05] <benlieb> I'm working with a video is reporting it's format as: JVT/AVC Coding, 592 x 416 AAC, 48000 Hz, Stereo (L R)
[07:05] <benlieb> and size: 720 × 505
[07:05] <benlieb> what is the 592 x 416 if not size?
[07:09] <cbsrobot-> yeah just write: -vf scale=xxx:yyy,setdar=uuu/vvv
[07:29] <benlieb> cbsrobot-: my real question is this: I have a lot of converted DVD videos with the dimensions above, and am trying to make "intro" videos with text from a database to add to the front of them. I'm just having trouble getting the sizes right. h264 is complaining about can't divide by 2...
[07:36] <cbsrobot-> benlieb: lets make it simple:
[07:37] <cbsrobot-> at least I know what you are dealing with
[07:37] <cbsrobot-> 592 x 416 is even, but I wonder where 720 × 505 come from
[07:38] <benlieb> yeah, I don't know...
[07:38] <benlieb> I don't understand what these 2 different dimensions refer to...
[07:39] <benlieb> jesus I figured it out.
[07:40] <benlieb> I'm viewing the video in quicktime, and the size it lists is the size of the video after any mouse resizing...
[07:40] <benlieb> ug
[07:40] <benlieb> so i had made it bigger a while back... hm
[07:40] <benlieb> Anyway the command I'll be using will be:
[07:40] <benlieb> `ffmpeg -y -i #{@dir}/intros/#{@lesson.id}.mp4 -i #{@dir}/raw_lessons/#{@lesson.id}.mp4 -filter_complex 'concat=a=1' #{@quality} #{@dir}/mp4_big/#{@lesson.id}.mp4`
[07:41] <benlieb> this command will just concat to vids together.
[07:41] <benlieb> my general question is do the sizes have to be exactly the same and aspect ratio too?
[07:41] <benlieb> I'm still trying to figure out if SAR and DAR are properties or calculations ...
[08:04] <Baked_Cake> is there a room for libfdk_aac
[08:05] <Baked_Cake> or aac in general, i got a question about the vbr
[08:15] <cbsrobot-> benlieb: not sure it does what you want, but without the actual console output I cannot help you - sorry.
[08:54] <benlieb> can someone point me to the filter_complex syntax docs? Can't find it on the website (which is looking good these days btw)
[09:33] <K4T> Hi! I need to convert 23.976fps film to 25fps aka film to PAL. As I know I have to speed up my input about 4% (video and audio). How I can achieve it? I am trying to use filters in ffmpeg: -filter_complex "[0:v]setpts=0.5*PTS[v];[0:a]atempo=2.0[a]" -map "[v]" -map "[a]" -r 25
[09:33] <K4T> But I don not have idea what values should I use
[09:33] <K4T> can someone help me with it?
[09:37] <Repe> hey, I am trying to convert alac -files to mp3 with ffmpeg and LAMEpreserving metadata and copying files from my musicserver to mounted mp3 player at the same command, keeping the folder structure as the same as in server. I dont know much about scripting and I am a bit lost here...Can someone help me with this one, please?
[10:00] <K4T> someone?
[15:27] <K4T> what difference is between trancoding and transrating?
[15:33] <sacarasc> What is transrating?
[15:33] <sacarasc> Transcoding is changing from one encoding to another.
[15:35] <K4T> I think transrating is when we encode video with the same codec
[15:35] <sacarasc> It seems transrating is keeping most of the stuff the same, but changing the bitrate.
[15:36] <K4T> yeah
[16:33] <John_Loki> hi, how to user ffserver without involving transcoding, meaning just forward the stream which is already H.264
[16:33] <John_Loki> use*
[16:40] <Fjorgynn> aha
[16:41] <Fjorgynn> -c copy?
[16:41] <Fjorgynn> or what
[16:41] <Fjorgynn> John_Loki: I don't know. Just wait
[16:42] <John_Loki> -vcodec copy
[16:43] <John_Loki> has been used but a lots of frames start missing
[16:44] <John_Loki> idea is that the steam which has been mapped on the stream elements should be streamed as it is, no transcoding required
[16:44] <John_Loki> stream*
[16:44] <John_Loki> feed element *
[17:49] <kaotiko> hi
[17:57] <fajung> Hi, I'm trying to convert and mkv to mp4 using ffmpeg like this: http://pastebin.com/J4K7a6uE | I can play the mp4 but in my WD TV Live can't play it, does anybody knows why?
[17:58] <Mavrik> fajung, add the output also to pastebin
[17:58] <Mavrik> so we can see the format of files involved.
[17:58] <Mavrik> also, why are you transcoding =
[17:58] <Mavrik> :)
[17:59] <fajung> >> ./a.log?
[18:00] <fajung> ok, I'll have to re encore it again, I'll came back as soon as it finished
[18:26] <fajung> Mavrik: here is the log: http://pastebin.com/a9getf8b
[18:40] <Mavrik> fajung, I see no reason why WD TV wouldn't play that
[18:41] <Mavrik> fajung, btw, why don't you just do ffmpeg -i <file>.mkv -codec copy <file>.mp4 ?
[18:41] <Mavrik> it's way faster and you don't lose quality
[18:46] <fajung> I'm doing it to get a smaller size file
[18:52] <sfan5> fajung: maybe WD TV Live only supports H.264 Main or Baseline
[18:53] <fajung> so, I'm new in all this things?
[18:55] <Mavrik> ah
[18:55] <Mavrik> lemme pull up tech specs of wd tv
[18:56] <fajung> I'm going to smash it against the wall
[18:57] <Mavrik> hmm, it seems that it should support the high profile
[18:57] <Mavrik> I see no reason why that wouldn't work :/
[18:57] <fajung> it play all the .HDTV.x264-LOL.mp4 that I have
[18:57] <Mavrik> try v:profile main
[18:59] <fajung> within the -vcodec libx264 ? | -vcodec libx264 v:profile mail ?
[19:06] <fajung> I can't sign in the wdtv forum to ask :'(
[19:18] <giamnt> hi
[19:22] <giamnt> I am encountering problems with the encoding of a file. [ avconv -y -i video.mp4 -c:a mp3 -c:v mpeg4 -vtag xvid video.avi ] returns me: [ Unknown decoder 'libmp3lame' ]
[19:23] <giamnt> Same thing with [ avconv -y -i video.mp4 -c:a libmp3lame -c:v mpeg4 -vtag xvid video.avi ]
[19:25] <sacarasc> #libav is the avconv channel.
[19:25] <giamnt> ubuntu 12.04 64bit, I have already contacted the channel #ubuntu and already reinstalled all lib, but nothing seems to work.
[19:25] <fajung> try to recompile ffmpeg
[19:26] <sacarasc> giamnt: This is for ffmpeg, not libav/avconv. You're asking the wrong channel.
[19:26] <fajung> https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[19:26] <giamnt> sacarasc yep same error with [ ffmpeg -y -i video.mp4 -c:a libmp3lame -c:v mpeg4 -vtag xvid video.avi ] = [ Unknown decoder 'libmp3lame' ]
[19:27] <sacarasc> On Ubuntu, usually the ffmpeg executable is just a front end for compatibility with the fork.
[19:27] <fajung> --enable-libmp3lame
[19:28] <giamnt> fajung you mena: ffmpeg --enable-libmp3lame etc etc ?
[19:28] <giamnt> *mean
[19:29] <fajung> try to compile ffmpeg as say in the copilation guide
[19:29] <fajung> I had the same trouble but with aac codecs
[19:30] <giamnt> fajung samething more simple, like edit a conf file?
[19:30] <giamnt> *something
[19:30] <fajung> follow the guide, it will work
[19:33] <giamnt> fajung ok, I'll try that....thanks by now :)
[19:40] <Andy2> Hi guys, i am playing around with -vf delogo and noticed that it removes the logo but changes the whole image color slightly. it gets a gray foggish tint.
[19:40] <Andy2> Is that a known bug?
[19:41] <Aiena> I had made a script a while bakc and it worked perfectly. ffmpeg seems to encode teh video filne but then I get "[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f28c80008c0] moov atom not found0/0
[19:41] <Aiena> file.mp4: Invalid data found when processing input" on playback.
[19:41] <Aiena> oops sorry that became multiline.
[19:42] <Aiena> Any ideas as to why. I'll pastebin the contents of my script here one moment.
[19:44] <Aiena> https://privatepaste.com/73746286c1 is the script
[19:50] <Aiena> OK found the issue
[19:50] <Aiena> it was badly exiting ffmpeg.
[19:50] <Aiena> script is ok
[19:51] <llogan> why do you upscale?
[19:51] <Aiena> becauswe someone s<id that videos are downscaled on playback in RGB mode so quality is better
[19:51] <Aiena> said
[19:52] <llogan> i don't understand
[19:53] <Aiena> Yeah that someone gave some explanation which I can no longer remember.
[19:53] <Aiena> I wrote that long back and it always worked it still does only never pressed q to properly terminate ffmpeg
[19:54] <Aiena> hadn't used that script for a while.
[19:55] <Aiena> it was long back when I made that.
[19:56] <llogan> you can use mkv instead of mp4
[20:02] <Mavrik> *grumbl* why does x264 segfault while using crop filter
[20:03] <llogan> Mavrik: is it reproduceable?
[20:04] <Mavrik> yeah, but it's from API use, so I have to rule out my messup first
[20:04] <llogan> The acronym "API" redenders me useless
[20:05] <zerwas> Is there a way to compress a video file and passing the desired file size in the command with ffmpeg?
[20:05] <Mavrik> zerwas, sadly no
[20:05] <Mavrik> you'll have to use ffprobe to get length and then calculate bitrate
[20:06] <zerwas> Mavrik: that's what I suspected. Thank you very much
[20:06] <llogan> zerwas: example https://trac.ffmpeg.org/wiki/Encode/H.264#twopass (although the math might be wrong in the example)
[20:07] <llogan> also https://trac.ffmpeg.org/wiki/FFprobeTips
[20:08] <zerwas> llogan: Thank you! I will try to figure it out
[20:09] <blight_> is there a way for interleaved audio/video packets to know how much the audio stream will be delayed to the video stream? what i mean is i have a file here where first come 25 video frames and then comes the audio for the first frame and i wonder how much delay to expect or how to handle this properly
[20:10] <blight_> i could either cache the video packets before decoding them to get to the audio packets or i could open the file twice, once for reading the video and once for audio i guess... anybody has another idea?
[20:11] <Mavrik> why not just get a large enough buffer?
[20:11] <Mavrik> there's an upper limit on how much video and audio can differ defined by the standard (to conform to devices with limited memory)
[20:12] <Mavrik> depending on format of course.
[20:12] <blight_> atm i just buffer decoded frames in the gpu memory and with full hd or even higher res it can use quite some memory
[20:12] <blight_> and i let the user set the maximum amount of gpu memory to use
[20:13] <Mavrik> well you buffer incoming packets before decoding of course.
[20:13] <Mavrik> why would you do that in gpu memory?
[20:13] <blight_> i dont do that atm ;)
[20:13] <Mavrik> they're not THAT large
[20:13] <blight_> yeah
[20:13] <blight_> but i wonder if there is any reason not to open the file twice because i thought about playing a file backwards which i think would be easier when you can treat audio and video as independent streams
[20:14] <blight_> otherwise keeping the audio correct when seeking backwards through the video while playing backwards is hard i think
[20:15] <Mavrik> well if you actually have a file, no reason :)
[20:15] <Mavrik> so yeah, open it twice if you have an actual seekable file :)
[20:15] <blight_> yeah i always have files
[20:16] <blight_> i think i might try that in the future and in the meantime cache the packets before decoding until i find an audio packet or something
[20:16] <blight_> should be easier to implement
[20:18] <Baked_Cake> its hard to beleive that aac_he can cut a stereo track down to 64K and sound perfectly fine
[20:18] <blight_> 64Kwhat? K bit/second?
[20:18] <Baked_Cake> ya
[20:18] <blight_> i dont like lossy codecs
[20:19] <blight_> i mean lossy audio codecs
[20:19] <Baked_Cake> i guess if i had $1000 speakers id probly be saying teh same thing
[20:19] <Hello71> if only you don't want to think you wasted any
[20:20] <Mavrik> Baked_Cake, yeah, I was rather impressed by HE-AAC quality at low bitrates as wel
[20:20] <Mavrik> very nice for mobile use
[20:20] <blight_> i am not sure if it's imagination or real but when you listen carefully and long enough on a mid-class hifi setup i believe you can hear "artifacts" of say 128kbit mp3
[20:20] <blight_> but even if say 320kbit mp3 sounds totally find i prefer using flac to store stuff because space is so cheap nowadays
[20:20] <Baked_Cake> id agree with u on mp3
[20:21] <Camusensei> hello guys, Having a bit of trouble usinf -vf subtitles here... I'm doing "ffmpeg -i video.mp4 -c:a copy -vf subtitles=subs.srt out.mp4" and the subs are not on the video... what am I doing wrong please? :)
[20:21] <Mavrik> blight_, yep, but sometimes you just don't have 320k of sustained bandwidth :)
[20:21] <blight_> vbr is the worst btw :p
[20:21] <Baked_Cake> i usual encode my mp3 at vbr seetting at about 224K
[20:21] <Mavrik> hmm, we just use AAC now for most use
[20:22] <blight_> probably depends on the exact vbr setting but when it goes down to 96 and you hear the background noise coming and going its no fun ;)
[20:22] <Baked_Cake> id use aac for my music but my car stereo isnt that fancy
[20:22] <Mavrik> blight_, also depends on encoder :)
[20:22] <Baked_Cake> i only use aac for tv shows if i have a flac source
[20:22] <Camusensei> by the way, the errors I have while encoding are
[20:22] <blight_> Mavrik: yeah, another issue with lossy codecs ;)
[20:22] <Mavrik> Baked_Cake, yeah, we do broadcast video, for music I just use whatever Google Play Music does
[20:22] <blight_> Baked_Cake: rockbox?
[20:22] <Camusensei> [Parsed_subtitles_0 @ 0000000005e30ea0] Neither PlayResX nor PlayResY defined. Assuming 384x288 and [Parsed_subtitles_0 @ 0000000005e30ea0] No usable fontconfig configuration file found, using fallback.
[20:23] <Camusensei> (note: this is a 1080p video)
[20:23] <llogan> Camusensei: windows?
[20:23] <Camusensei> llogan: yes
[20:23] <llogan> some other users had a similar issue i think. i don't know how any of that was resolved since i'm using linux.
[20:24] <Camusensei> llogan: ok I'll do that on linux and come back to you. thank you for the help
[20:24] <llogan> (they were using builds from Zeranoe
[20:24] <Baked_Cake> blight_: i use foobar on my pc, whats rockbox?
[20:25] <blight_> mp3 player firmware
[20:25] <blight_> i thought maybe for your car stereo :p to play aac
[20:25] <Baked_Cake> interesting
[20:26] <Baked_Cake> the idea of being able to flash my stereo's firmware never crossed my mind
[20:26] <Baked_Cake> its probly too old tho
[20:28] <blight_> dunno i think rockbox exists since like 2000
[20:28] <blight_> worth a look ;)
[20:28] <llogan> Camusensei: possibly related thread but i didn't read it much: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=10&t=318
[20:29] <Baked_Cake> yea from what im reading i dont even have to flash the stereo
[20:29] <Baked_Cake> it looks like this is mostly for mp3 players tho
[20:30] <Baked_Cake> ipods and such
[20:30] <blight_> yeah
[20:43] <Camusensei> llogan: I'm looking into it while it compiles ffmpeg ^^
[20:51] <Baked_Cake> o it looks like i can buy a source input adapter for my ipod that the steroe normally uses for the external disc changer
[20:52] <Baked_Cake> doesnt work if i just plug it into the usb input
[20:52] <Baked_Cake> if that works then my ipod courd do all the decoding
[21:00] <Baked_Cake> my ipod only hold 4gb tho, i should consider getting a new mp3 player
[21:06] <Baked_Cake> damn id have to iether get an ipod or a jvc player
[21:06] <Baked_Cake> what a scam
[21:24] <Aiena> llogan now I remember why UI upscaled so the video res is always a power of 2. ffmpeg used to complain otherwise
[21:49] <JayBlanc> Hi. Quick question, does ffmpeg return an error value if it encounters any kind of decoding/encoding error, even if it was able to continue the encode?
[21:51] <JayBlanc> The potential error values returned by ffmpeg don't appear to be documented, and this makes it hard to use in a script. Does anyone know when/what error codes are returned and what they indicate?
[21:55] <Aiena> hmm I am not sure. But normally when ffmpeg returns and error it highlights the output in red and gtells you waht the problem was.
[21:55] <Aiena> *returns an error
[21:56] <JEEB> JayBlanc, there's a setting to make ffmpeg fail at the first "error" it comes up with, but otherwise I would guess the result is zero unless decoding failed completely in some way at some point
[21:56] <JEEB> although reading ffmpeg.c most probably is the best way to learn :P
[21:56] <JayBlanc> Ah. It... appears to be set by a global variable.
[21:56] <JayBlanc> That's... Not great.
[21:56] <JEEB> "global variable"? AFAIK it was a setting like any other
[21:57] <JayBlanc> I just read the source code.
[21:57] <JEEB> I remember helping a person with this but I've since forgotten the setting :P
[21:58] <JEEB> and yes, if global var in C context then sure, not that I remember the details
[21:58] <JayBlanc> There's a global variable defined called "main_return_code" that gets used as the return value.
[21:58] <JEEB> but it sounds like it's the simplest way
[21:58] <JayBlanc> That's a bad idea.
[21:58] <JEEB> I don't disagree
[21:58] <orib> -xerror
[21:58] <JEEB> I've not looked at ffmpeg.c too much, thankfully
[21:58] <JEEB> mostly lavf and lavc internals
[21:59] <orib> ffmpeg -help full is your friend - it documents "-xerror error" as "exit on error"
[21:59] <orib> I guess it does what you want, though I'm not sure
[21:59] <JayBlanc> It means that some decoders will, and from what I've been seeing with trying to write a wraper script, are setting the main return value to some positive value if they encounter any error even if it's recoverable.
[22:00] <JayBlanc> Orib: Thank you, but that is not related to the question I asked.
[22:00] <JEEB> the decoders themselves are not setting any "global return value" as far as I know
[22:00] <JEEB> they just return a value as far as I know
[22:00] <orib> JayBlanc: Then can you rephrase the question? I don't understand it. Unless you're referring to the library rather than the executable?
[22:01] <JayBlanc> orib: Do you understand what I mean by 'return value' of a unix program?
[22:01] <JEEB> but yes, an error can be "recoverable" or "unrecoverable"
[22:01] <JEEB> and if you tell ffmpeg you want to exit on error it will do so with everything'ish
[22:01] <JEEB> there are some other modes too, though, IIRC
[22:01] <orib> Yes. When ffmpeg succeeds it returns 0 like any good old program
[22:01] <JayBlanc> Ah. Yes, you'd think that.
[22:01] <orib> and -xerror will supposedly make it exit with an error if it sees one
[22:01] <JayBlanc> It does not.
[22:02] <orib> oh ....
[22:02] <orib> It'
[22:02] <JayBlanc> See above: re Global variable that anything can set to make the return value be positive.
[22:02] <JayBlanc> And apparently some things are.
[22:02] <orib> It's been a while since I've used the cli...
[22:02] <orib> Silly me, then.
[22:03] <JayBlanc> Which makes ffmpeg kind of hard to use in wraper scripts when you want to use it to repair corruptable input streams.
[22:03] <JayBlanc> Because some decoders apparently set that global return value for main if they *ever* see any kind of error.
[22:03] <JEEB> they don't specifically set that
[22:03] <JEEB> something else uses it when calling the decode function
[22:04] <JEEB> and then the actual decode function just returns an error value depending on circuimstances
[22:04] <Camusensei> llogan: Nope, doing the same on linux :/
[22:04] <JayBlanc> Well, something seems trigger happy on setting a positive value on that global variable.
[22:05] <orib> JayBlanc: consider grepping the error stream
[22:05] <JayBlanc> How would that help?
[22:05] <orib> Ignore the return code, see if you had an error somewhere along the way
[22:05] <JEEB> JayBlanc, basically whatever is calling av_read_frame and avcodec_decode_video2 is then setting the return code :P
[22:05] <JEEB> the libraries don't touch any "global return code"
[22:05] <JEEB> :P
[22:06] <JEEB> aanyways, you will probably want to look into the code path of the demuxer or decoder you're planning on using for further information
[22:06] <JEEB> it could hint at the option you are interested in
[22:07] <JayBlanc> Something is causing ffmpeg.c's main to return a positive value, and ffmpeg.c returns that global variable as it's return value.
[22:07] <orib> JayBlanc: by "error stream" I meant the stderr (/dev/fd/2, /dev/stderr, 2>, whatever you call it)
[22:07] <JEEB> yes, and I'm saying it's not the decoders or demuxers since they don't touch that
[22:07] <JEEB> it's whatever is calling those :P
[22:07] <JEEB> (and encoders and muxers)
[22:07] <JEEB> also, #ffmpeg-devel could possibly be more interesting when discussing such specifics
[22:08] <JayBlanc> orib: Is there a unique common indicator I can search for in the error stream that indicates an unrecoverable error?
[22:08] <JEEB> esp. since no-one of the more knowledge'able side seems to be active right now here
[22:08] <JEEB> (I can't exactly know all of the parts of the code base)
[22:08] <JayBlanc> Well, return values are really supposed to be documented on the user side of things.
[22:09] <JEEB> if they are the error values as-is they're documented in libavutil or so I would guess
[22:09] <orib> JayBlanc: Not that I know of - I would guess the answer is "no" if you need to support all codecs, but "probably yes" if you only need to support one or two, though you'll have to look for them in the source code.
[22:09] <JEEB> but yes, documentation could always be better
[22:10] <JEEB> I'm just saying that you will most probably poke someone more knowledge'able of the command line specifics on -devel, since it's mostly end users here who really have no idea how ffmpeg works internally :P
[22:10] <llogan> Camusensei: and please provide subtitles file
[22:10] <JEEB> I know how lavc/lavf work to a point
[22:10] <JEEB> but I haven't worked on the cli side of things
[22:10] <JEEB> :P
[22:10] <Camusensei> llogan: doing that
[22:11] <JayBlanc> At the moment the short term solution seems to be to make another wrapper script that just serves to spoof a return value.
[22:14] <JEEB> if I were less tired I'd actually look into it again as I did for this one other guy, but if you have no interest I'm glad I didn't :P
[22:14] <JayBlanc> And since I can't actually be sure that I'd know what to look for in fatal error messages, there doesn't seem to be any point to grepping the stderr output.
[22:14] <JEEB> also seriously, poke -devel since as I said there seem to be no developers active here :P
[22:15] <JEEB> if you are actually goddamn interested in how shit works
[22:15] <Camusensei> llogan: http://sprunge.us/MReH
[22:15] <Camusensei> subs uploading...
[22:20] <Camusensei> llogan: http://c.thican.net/subs.srt subs here
[22:33] <llogan> Camusensei: i'm confused. subtitles filter requires libass, but I don't see --enable-libass in your configure. i expect to see "No such filter: 'subtitles'" in your console output
[22:34] <Camusensei> llogan: yeah, I don't know why it's not in there. but is was compiled with it, I'm sure of that. http://prntscr.com/4gf1of
[22:37] <llogan> Camusensei: your srt works for me. i don't know what is going on with your build. I'll blame gentoo.
[22:38] <Camusensei> llogan: well, zeranoe on windows does the same, so it's maybe not gentoo's fault
[22:38] <llogan> that might be a separate issue
[22:38] <llogan> but i don't know.
[22:38] <Camusensei> llogan: do you have --enable-libass displayed when you run your ffmpeg?
[22:38] <llogan> yes
[22:38] <llogan> but you can get away with using ass filter instead
[22:39] <Camusensei> llogan: I'll dig around that then.
[22:39] <llogan> ffmpeg -i input.srt output.ass; ffmpeg ... -vf ass=output.ass
[22:39] <Camusensei> ah, --enable-libass is displayed in my zeranoe version
[22:39] <llogan> wait...i might be wrong.
[22:40] <llogan> ass just doesn't require lavc and lavf (I was thinking of libass instead)
[22:41] <llogan> and, obviously i suppose, ass does need libass as shown in configure.
[23:21] <benlieb> is there any way with ffplay to get an idea of "where" you are in the video while playing?
[23:25] <llogan> benlieb: the last line in the console output shows the time elapsed in seconds
[23:25] <benlieb> llogan: yes but that gives me no indication of where I am compared total time of the video
[23:26] <benlieb> i've read the docs and I can't find anything.
[23:26] <benlieb> seems like a huge oversight
[23:26] <llogan> you could use mplayer, vlc, mpv, etc
[23:27] <llogan> or a fancy filtergraph
[23:27] <llogan> and drawtext
[23:27] <benlieb> llogan: I have other players, but I'm looking to take "thumbnails" of videos and I need accuracy to the ss.xxx
[23:28] <benlieb> so I need the decimal time, which no other player gives me that I know of
[23:28] <benlieb> just a bit like flying blind
[23:29] <benlieb> it would have been trivial to include the percentage in text on that last line
[23:30] <benlieb> there may be some combination of options that would get this...
[23:31] <llogan> ffplay -vf "drawtext=fontfile=VeraMono.ttf: timecode='00\:00\:00\:00': r=24000/1001: x=(w-tw)/2: y=h-(2*lh): fontcolor=white: box=1: boxcolor=0x00000000@1" input
[23:32] <llogan> possibly not accurate
[23:32] <benlieb> yeah, doesn't work but i get the idea
[23:46] <ubitux> huh?
[23:46] <ubitux> don't use timecode
[23:46] <ubitux> it's a smpte thing
[23:46] <ubitux> use text=%{pts\:hms} instead
[23:47] <ubitux> and you don't need the rate option then
[23:47] <ubitux> llogan, benlieb ^
[23:48] <ubitux> fontfile is also useless if you have a fontconfig
[23:50] <benlieb> can't get that command to work. think it has to do with font paths
[23:51] <ubitux> --enable-fontconfig allows you not to specify it
[23:52] <ubitux> then just -vf "drawtext=text='TS\:%{pts\:hms} N\:%{n}':boxcolor=white:box=1"
[23:52] <ubitux> should do what you want
[23:52] <ubitux> anyway gtg, gl
[00:00] --- Tue Aug 26 2014
1
0
[00:00] <iive> Case: yeh, that's common thing among dictators ;)
[00:00] <ubitux> kierank: i fucking hate chatty talks in real life because it's always a waste of time
[00:00] <iive> people are too easily manipulated in real life talks.
[00:00] <ubitux> kierank: and unless it's a very technical one, i will just avoid it alltogether
[00:00] <kierank> ubitux: you can come to the chatty talk to discuss the shared mailing list, the libav people can agree (and/or compromise)
[00:01] <ubitux> yes but i don't care
[00:01] <ubitux> i'm fine & neutral with that
[00:01] <kierank> ubitux: you just said that you don't like it when you comment and libav says you are saying ffmpeg is better
[00:01] <ubitux> i don't need to go to a meeting to ear ppl talk about such trivial thing
[00:01] <kierank> ubitux: again, will you be contacting everyone to make sure it will be ok
[00:01] <kierank> this is what i don't understand
[00:02] <kierank> you complain about libav but then when i suggest a way to improve the situation you say it's too hard
[00:02] <ubitux> you will never have everyone in real life
[00:02] <ubitux> but you will reach everyone through the 2 ml
[00:02] <ubitux> why the hell would you want to ever choose the 1st solution?
[00:02] <kierank> because look at where we are now
[00:03] <kierank> the second solution has just been potshots for the last 3.5 years
[00:03] <ubitux> it's an excuse
[00:04] <kierank> anyway clearly you don't give a shit either about users and think for some reasons that getting ffmpeg into debian will solve everything
[00:04] <kierank> even though libav controls the ffmpeg api
[00:04] <Case> so debian is responsible for this mess
[00:04] <kierank> lol
[00:05] <kierank> it's a misguided belief that debian having ffmpeg will solve everything
[00:05] <ubitux> having ffmpeg in debian will solve a lot of problems for the users kierank
[00:05] <iive> agree!
[00:05] <ubitux> kierank: everything, maybe not, but it will definitely appease our users
[00:05] <Case> libav only has users because something lied that ffmpeg is depracated and libav is the new version
[00:06] <ubitux> kierank: we will probably still be limited with the api evolutions
[00:06] <ubitux> kierank: but first, we need to make sure our users can access our improvements
[00:06] <ubitux> because currently, our 3 years of developement are void
[00:07] <ubitux> then maybe, we can go discuss about what to do with the api evolutions
[00:07] <ubitux> and i don't mind discussing those in a common ml between libav & ffmpeg
[00:07] <ubitux> i'm not a sysadmin so i won't take the responsibility of such setup
[00:08] <ubitux> but we can definitely send a suggestion x-posted to both ml
[00:08] <kierank> ubitux: what about users who just want to decode a video and see half the web talking about ffmpeg and half the web talking about libav
[00:08] <kierank> and don't understand which to use
[00:08] <ubitux> they will look at what's available in their target OS
[00:08] <iive> kierank: you use the one that comes with your distro. Debian and Ubuntu comes wtih libav
[00:09] <jamrial> what case said is true to some extent. i've found quite a few cases where people assumed libav replaced ffmpeg because of the bogus "deprecated" ffmpeg package that used to be in debian
[00:09] <kierank> jamrial: i won't disagree
[00:09] <ubitux> "a few"? lol
[00:09] <kierank> and had a big argument with libav people about that
[00:09] <ubitux> go join #ffmpeg
[00:09] <jamrial> then there's gentoo now that changed the priority of the "ffmpeg" virtual package from libav to ffmpeg
[00:09] <jamrial> the ffmpeg virtual package by default install libav. IMO that's hella shaddy
[00:10] <jamrial> My bad
[00:10] <jamrial> the other way around
[00:10] <jamrial> changed it from ffmpeg to libav
[00:10] <ubitux> kierank: do you know a sysadmin willing to setup such ml?
[00:11] <ubitux> like, a ml dedicated to any API changes for both projects
[00:11] <kierank> ubitux: probably but that's not the point
[00:11] <kierank> the point is social
[00:11] <iive> jamrial: is it possible to find out who did that? I've heard about it before
[00:11] <kierank> getting epople to agree to use it
[00:11] <ubitux> kierank: then send a mail to both ml
[00:12] <ubitux> kierank: no one ever suggested this on the ml afaik
[00:12] <jamrial> well, Luca is a gentoo dev, so i assume he was an influence in the decision
[00:12] <iive> jamrial: but can he do it himself?
[00:12] <ubitux> kierank: i don't think that's a bad idea at all to have a common ground for api evolutions
[00:13] <ubitux> kierank: the idea that both projects must send their proposition to that ml sounds ok to me
[00:13] <kierank> yes but it needs to be agreed
[00:13] <jamrial> no single person can make a change like that. but a person can influence the decision a group makes
[00:13] <ubitux> i expect it will not work but well
[00:13] <ubitux> (i expect ppl from one project trying to block the other one)
[00:13] <kierank> ubitux: i wouldn't say discussions are fianl
[00:13] <ubitux> but yeah sure we can give it a try
[00:13] <kierank> but just to have discussions
[00:13] <kierank> ubitux: yes so my point is your discuss it first and then do it
[00:14] <kierank> not just do it, nothing happens and then say libav aren't palying ball
[00:14] <ubitux> sure
[00:14] <iive> jamrial: the ffmpeg gentoo packager have not been... invited to such discussion. I had his blog post somewhere...
[00:14] <kierank> which is basically what michael does
[00:14] <ubitux> kierank: i really don't think any ff dev (or maybe CE but i'm not even sure) would disagree with such ml
[00:14] <kierank> and?
[00:15] <kierank> the point is not about ffmpeg agreeing
[00:15] <ubitux> well then just find a sysadmin to setup it
[00:15] <kierank> the point is about both sides
[00:15] <kierank> sigh
[00:15] <ubitux> well, go ask libav?
[00:15] <ubitux> i can do it if you want but that won't really work
[00:15] <ubitux> as i'm not a neutral folk
[00:16] <kierank> libav want to discuss this in person
[00:16] <kierank> but you don't
[00:16] <kierank> and therefore they can say they tried and ffmpeg didn't respond
[00:16] <ubitux> well, if c & asm developers can't use e-mails then i can't do anything about that
[00:16] <kierank> it's not they can't
[00:16] <kierank> they are just fed up of the potshots for the last 3.5 years
[00:16] <ubitux> they don't want to right, but they have no reason
[00:16] <ubitux> it's just an excuse
[00:17] <kierank> it's not
[00:17] <ubitux> they know michael won't come
[00:17] <kierank> who wants tot hear the same shit again and again
[00:17] <ubitux> and use that as an excuse to not communicate
[00:17] <kierank> cf debian-devel
[00:17] <ubitux> same shit will happen irl
[00:17] <kierank> it doesn't
[00:17] <ubitux> then it's twisted
[00:17] <kierank> who would have thought people behave differently in different environments
[00:18] <ubitux> there is no reason to talk about that when setuping a common ml
[00:18] <ubitux> yes, irl they behave in the most hypocritical way
[00:18] <kierank> it is not hypocritical to behave differently depending on environment
[00:19] <kierank> people post things to ML that they wouldn't sat to people's face
[00:19] <kierank> look at all the internet trolls
[00:19] <ubitux> yes, because they are intimidated
[00:19] <kierank> in general
[00:19] <ubitux> or just don't want to express their thoughts
[00:19] <kierank> or because they are being polite
[00:19] <ubitux> because they don't have time to form them
[00:19] <kierank> (who would have thought...)
[00:19] <ubitux> yes, so they are hypocritical
[00:20] <kierank> so being cordial for the sake of progress is hypocritical
[00:20] <kierank> right
[00:20] <ubitux> (aka they try to appear nice)
[00:20] <kierank> compromise is hypocritical too
[00:20] <ubitux> no, it's a deal
[00:20] <kierank> let's stick to our 100% staunch views
[00:20] <kierank> otherwise we'll be hypocrites
[00:20] <kierank> mans is an author of swresample you know
[00:20] <kierank> ffmpeg steals libav's work
[00:20] <kierank> all these moronic views
[00:20] <kierank> let's repeat them all because we'd be hypocrites
[00:21] <kierank> let's not acknowledge mistakes
[00:21] <kierank> we'd be hypocrites
[00:22] <kierank> totally bizzare way of interacting with people
[00:23] <iive> kierank: what do you want?
[00:23] <kierank> both sides to act like adults
[00:23] <kierank> so as not to screw the users
[00:23] <kierank> otherwise go and join gpac
[00:23] <kierank> and be a research project with no users
[00:24] <kierank> also btw people don't use ffmpeg/libav based on their distro
[00:25] <iive> define what do you mean by that.
[00:25] <kierank> they use it based on whether it works
[00:25] <kierank> or if they can get it to work
[00:25] <iive> they first try the tool they can reach easily, then they look for another tool that does what they need.
[00:25] <kierank> iive: stop posting misleading stats/facts on the ml. talk about making some co-operative work
[00:25] <kierank> iive: not tool
[00:26] <kierank> i am talking about api usage
[00:26] <kierank> anyway these days people use github
[00:26] <iive> well, the libav take-over/fork happened because they wanted to change api and do thing differently.
[00:27] <ubitux> kierank: mail sent
[00:27] <ubitux> oups
[00:27] <ubitux> wrong dest
[00:27] <iive> by definition this is bad for the api users.
[00:27] <kierank> ubitux: congratulations, you'll get the response from libav you wanted
[00:27] <kierank> you're baiting them and they'll take the bait
[00:27] <kierank> and then you can say they didn't want to work with you
[00:27] <ubitux> i messed up the mail dest
[00:28] <iive> ubitux: where did you sent it? debian?
[00:28] <ubitux> ffmpeg.org :p
[00:28] <iive> ok, not big deal...
[00:29] <ubitux> kierank ??
[00:30] <ubitux> kierank: sorry but... what's wrong with my suggestion?
[00:30] <iive> kierank: libav simply have different priorities. they prefer cleaner code and api. this would remain even if all people who were at the fork leave the project.
[00:30] <kierank> it's the wrong environment to make it
[00:30] <kierank> nothing is wrong with the suggestion itself
[00:30] <ubitux> michaelni: oh shit, it actually compiles? :)
[00:30] <kierank> both mailing lists are full of smears so they are going to assume this is another smear
[00:30] <ubitux> kierank: real life isn't any better
[00:31] <kierank> like all the quotes about being friendly with libav
[00:31] <kierank> ...
[00:31] <kierank> you were literally at each others throats IRL
[00:31] <kierank> yup
[00:31] <ubitux> i don't want to talk to libav in real life
[00:32] <kierank> no shit
[00:32] <iive> well, we can keep on hating each other, but at least point each-others bugs?
[00:32] <ubitux> because i don't want to play the game with the one making the rules
[00:32] <kierank> nobody will make rules
[00:32] <kierank> i don't want to talk to neither ffmpeg nor libav
[00:32] <kierank> but i have to
[00:32] <ubitux> real life is not a neutral ground
[00:32] <kierank> vlc is
[00:32] <kierank> as j-b said it's much bigger than the petty fighting
[00:32] <ubitux> anyway, i believe the ml thing is a good idea
[00:33] <kierank> yes but it will get shot down
[00:33] <ubitux> if libav agrees then be it
[00:33] <ubitux> +dis
[00:33] <kierank> and then you prove your point
[00:33] <ubitux> kierank: not sure
[00:33] <kierank> and you score a 9999:9998 in the libav/ffmpeg cold war
[00:33] <ubitux> where did they score 9998?
[00:33] <ubitux> :o
[00:34] <kierank> 9 998 then
[00:34] <kierank> since they like cosmetics
[00:34] <ubitux> i like 9999:9.998
[00:34] <kierank> yes but the dot could be a decimal point
[00:34] <kierank> ...
[00:34] <ubitux> that's the point
[00:34] <ubitux> ;)
[00:34] <kierank> nice cosmetic argument
[00:34] <iive> kierank: do you know what would be interesting. A maillist, where all identity is hidden. so nobody could guess who is who and from what project he is.
[00:35] <michaelni> ubitux, yes, also i think thilo has a ppc IIRC
[00:35] <ubitux> michaelni: ah, ok cool
[00:35] <ubitux> i'll wait for a proper
[00:35] <ubitux> i'm happy it compiles :p
[00:36] <ubitux> kierank: really i don't see how they can shot down this
[00:36] <ubitux> i'm actually starting to like the idea
[00:36] <kierank> they'll shoot it down because it came from you
[00:36] <kierank> because this problem is not technical but socail
[00:36] <ubitux> you didn't want to write the mail&
[00:37] <kierank> because i want to solve social problems properly (if painful for some, myself included)
[00:37] <ubitux> i told you it wouldn't be easy if i started such comminication
[00:37] <ubitux> it's not a "social" problem
[00:37] <ubitux> it's a braindead one
[00:37] <ubitux> there is nothing social about that
[00:37] <iive> kierank: how do you want to solve it?
[00:37] <ubitux> iive: he wants michael to go to VDD
[00:38] <iive> by real life meeting?
[00:38] <ubitux> so all problems magically solve themselves
[00:38] <ubitux> yes
[00:38] <kierank> whether you like it or not michael going to vdd is a blocking factor
[00:38] <ubitux> no
[00:38] <kierank> it was even said in the ffmpeg meeting last year
[00:38] <kierank> by myself and thierry
[00:38] <ubitux> the blocking factor is libav willing michael in real life at vdd
[00:38] <kierank> what are they going to do?
[00:38] <kierank> murder him
[00:39] <ubitux> they can just get over it
[00:39] <ubitux> it's like a little switch in your brain
[00:39] <ubitux> i'm sure they can achieve that
[00:39] <iive> kierank: I think they hate him enough for that one too.
[00:40] <ubitux> i wouldn't actually be confident about michael not being murdered there
[00:40] <iive> but most likely they would like to shame him
[00:41] <ubitux> yes, like harassing him to make him admit whatever they fancy, or public excuses or whatever
[00:41] <kierank> and a good moderator will stop that
[00:41] <ubitux> waste of time
[00:41] <ubitux> let's just keep trying to get them replying to mails
[00:42] <iive> kierank: imho, libav should be left to sink on its own weight.
[00:43] <kierank> lol
[00:43] <kierank> because all the things libav are experts on will suddenly just move to ffmpeg
[00:43] <iive> k&r and alphabetical ordering?
[00:44] <kierank> arm asm, rtsp, etc
[00:46] <ubitux> kierank: let's try to fill that gap
[00:46] <ubitux> actually, we are indeed in need of arm expert
[00:47] <kierank> you can't any more so than they can with swscale
[00:47] <kierank> they wrote the code
[00:47] <kierank> they understand it
[00:47] <iive> kierank: ?
[00:47] <ubitux> i don't think it's insurmountable
[00:48] <iive> afair mans wrote most of the arm asm, and he rewrote most of that he didn't wrote. And he left libav quite long ago.
[00:48] <kierank> anyway i didn't post on debian-devel but that fact that one person understands most of ffmpeg isn't a selling point against libav
[00:48] <ubitux> iive: at least jannau is writing some asm
[00:48] <ubitux> iive: some *arm* asm
[00:48] <kierank> it's a euphemism for ffmpeg parts are unmaintainable
[00:49] <ubitux> it's the same for libav, really
[00:49] <iive> actually worse. because nobody there understands it as a whole.
[00:49] <iive> so they "clean it up" bit by bit.
[00:50] <ubitux> they solve the problem by ditching parts they don't understand, breaking some stuff in the process
[00:50] <ubitux> they might end up with a codebase they masterize, but at what cost?
[00:51] <kierank> better than a codebase only one person understands imo
[00:51] <ubitux> tell that to the users
[00:51] <kierank> yeah the users report a bug and only one person is able to fix it and if that person is busy they are fucked
[00:52] <ubitux> yes, better drop the feature
[00:52] <kierank> if it's a security related issue perhaps yes
[00:52] <kierank> or postproc
[00:52] <ubitux> it's better to drop the feature than asking michael
[00:53] <kierank> sometimes better to start again than build on a base of fragile
[00:53] <iive> kierank: even libav are not that stupid.
[00:53] <ubitux> except for users
[00:54] <kierank> iive: they've done it many times
[00:54] <kierank> lowres
[00:54] <kierank> postproc
[00:54] <kierank> et
[00:54] <ubitux> yes
[00:54] <ubitux> and lowres is useful for users
[00:54] <ubitux> postproc as well
[00:54] <kierank> yes but it used to crash randomly
[00:54] <iive> kierank: i mean, not stupid enough to start from clean slate.
[00:54] <ubitux> and now it's fixed in ffmpeg?
[00:54] <kierank> just like if there was an arm asm crash
[00:54] <kierank> who would fix it in ffmepg
[00:56] <ubitux> someone willing to learn arm asm i guess
[00:57] <ubitux> we'll probably get such maintainer at some point in the future
[00:58] <ubitux> we already have some people ± friendly with arm here, and i believe we have mind flexible enough to look into such thing
[00:58] <ubitux> the answer will definitely not be to ditch the arm asm
[00:59] <jamrial> if the crash is in ffmpeg, then it's also in libav, since all the arm code is the same between the two projects
[00:59] <kierank> you know well that isn't possible for parts of swscale or postproc or whatever
[00:59] <kierank> it's so complex nobody understands it
[01:02] <kierank> well one person
[01:09] <BBB> kierank: youre generally clever, but now youre utterly short-sighted
[01:10] <BBB> kierank: you know theres some people in a community that dont particularly need any prescient knowledge of any kind to fix bugs in a product, right?
[01:10] <BBB> kierank: like, me?
[01:10] <BBB> I can fix any bug in any product - wanna argue over that? Id love to
[01:10] <kierank> BBB: sure but by your own admission in the beginning of swscale it took a long time for you to understand it
[01:12] <kierank> but one of the "arguments" for debian to use ffmpeg on the list was that only one person really understands all of it
[01:12] <kierank> so users are better using ffmpeg
[01:12] <kierank> which is kinda true
[01:12] <kierank> but it mostly says some of the code is unmaintainable
[01:12] <BBB> I wasnt fixing bugs
[01:12] <BBB> I was trying to redesign the whole thing
[01:12] <BBB> thats utterly different
[01:13] <BBB> I do think some senior committers in libav are utterly clueless
[01:14] <BBB> but thats a different thing again
[01:14] <BBB> (then again, I believe it was a ffmpeg dude that started using commit count as a metric, so I guess were even there)
[01:32] <iive> BBB: i'm quite sure that was Diego too
[01:50] <Timothy__Gu> ubitux, BBB: Libav's lack of Michael reminds me of one of Michael's random quotes
[01:50] <Timothy__Gu> Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better.
[01:59] <BBB> Timothy__Gu: sorta& I do think you can learn a lot from rewriting something, that is, you will understand it better as you rewrite it, as long as you rewrite it functionality-complete
[01:59] <BBB> Timothy__Gu: but yeah, a full rm -fr followed by a rewrite from scratch is silly
[02:06] <Timothy__Gu> Hm you have a point
[02:06] <Timothy__Gu> Gotta go
[02:12] <Daemon404> BBB, rm -rf and no rewrite would suffice for some code out there
[02:12] <cone-41> ffmpeg.git 03James Almer 07master:b140b51ebbc2: lavc/tiff: add support for LZMA compression
[02:12] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:ab1e4312887d: avcodec/tiff: Make pixel format checks tighter
[02:31] <Compnn> whoa kierank angry
[02:32] <kierank> no not really
[02:35] <Compnn> i'd kinda like to see michael go to vdd now just to prove that in real life talks wont change a thing
[02:35] <Compnn> :P
[02:40] <Compnn> j-b can setup a neutral ml for us :P
[02:44] <pross-au> Dumb question about FFmpeg Debian package: What's hold this up?
[02:45] <pross-au> There appears to be endless discussion on the ML by non-influential people. That is okay, its great to vent sometimes. But as an irregular contributor its hard to appreciate the issues and important stakeholders.
[02:45] <Compnn> pross-au : i think andreas knows more than we do about debian internals
[02:45] <Compnn> i think?
[02:46] <Compnn> last i heard the ftp masters havent reviewed it
[02:46] <Compnn> and security made some mentions about not wanting to have both
[02:46] <Compnn> so ... stalemate
[02:47] <pross-au> ok. that helps a bit.
[02:47] <Compnn> its across several bugs in debian bugzilla and on multiple mailinglists i think?
[02:47] <Compnn> if you follow all of andreas's mails , i think the links to all of the bugs are in there
[02:49] <Compnn> kierank : i was told point blank by libav devels that some of them didnt want to work with michael (and carl). you think thats changed in one year?
[02:49] <Compnn> at vdd13 that is
[02:49] <kierank> dunno
[02:49] <Compnn> (in person)
[02:50] <Compnn> ok , i was just curious if you had news about it
[02:50] <Compnn> because i havent had much communication with them
[02:51] <kierank> generally speaking they have said they would at least have a discussion
[02:51] <kierank> i won't speak for anyone in particular
[02:51] <Compnn> no problem, i also am not remembering any names...
[02:53] <pross-au> Compnn: what will be the name of the FFmpeg+LibAV unification project
[02:54] <Compnn> you mean the unification ml or the name of the projects when combined?
[02:55] <pross-au> either
[02:55] <kierank> doubt there will be a reunification
[02:55] <kierank> a mutual respect at best
[02:55] <pross-au> What! Stop being negative.
[02:55] Action: Compnn has serious doubts too
[02:57] <Daemon404> Compnn, even sme ffmpeg devels dont want to work with carl
[02:57] Action: Daemon404 runs
[02:58] <Compnn> guys need to stop hating on each other
[02:58] <Compnn> just send author mails to spam if they bother you that much
[02:58] <Compnn> review on -cvslog
[02:58] <Daemon404> it makes a bug tracker essentially useless if the guy running it hates you
[02:58] <Daemon404> just fyi ;)
[02:59] <Daemon404> anyway kierank is correct
[02:59] <pross-au> Daemon404: i was once told, always treat the janitors kindly. They can make your life hell.
[02:59] <Daemon404> pross-au, in this case the janitor started it
[02:59] <Compnn> i've made suggestions how to fix the bug trac problem , maybe i should try to make my suggestions into policy
[03:00] <Compnn> Daemon404 : imo you should just send your bug reports direct to the maintainer of said code
[03:00] <Compnn> if the bug tracker isnt working for you
[03:00] <Compnn> ;)
[03:00] <Compnn> i know others have had problems with the tracker
[03:00] <Compnn> i know
[03:00] <Daemon404> lol maintainers
[03:01] <Compnn> yes we have a MAINTAINERS file
[03:01] <Daemon404> as if most of the codebase has real maintainers
[03:01] <Compnn> pick the file.c and send it to that person
[03:01] <Compnn> an email
[03:01] <Daemon404> or even ones listed still exist
[03:01] <Compnn> you just want to argue :P
[03:02] <Compnn> if you dont want my suggestions, fine
[03:02] <Compnn> i still like ya
[03:02] <Daemon404> im a realist
[03:03] <kierank> Daemon404: we should co-maintain avresample
[03:03] <kierank> wm4 should join
[03:06] Action: Daemon404 sleeps .. 2am
[03:07] <Compnn> kierank saw ffmpeg and libav devs at vdd13. those two groups rarely stayed in the same room even
[03:08] <BBB> kierank: avresample is significantly slower for the code that I looked at
[03:08] <BBB> kierank: so I find your opinion impractical - yes, speed matters
[03:08] <kierank> that was a joke
[03:08] <Compnn> i liked the "libavcodec problems" meeting though. that was fun
[03:09] <kierank> BBB: because michael was/is angry that myself, Daemon404 and wm4 use avresample
[03:09] <BBB> ?
[03:09] <BBB> sorry I actually failed to parse that
[03:10] <kierank> it's 2am sorry
[03:10] <kierank> michael is angry that wm4, Daemon404 and me use avresample
[03:10] <kierank> instead of swresample
[03:10] <BBB> hm...
[03:10] <kierank> so i said us three should be maintainers
[03:10] <BBB> well, its a free world
[03:10] <BBB> lots of democrats are unhappy with republicans, and vice versa
[03:10] <kierank> to be fair the inline asm is gone
[03:10] <BBB> I dont see any issue
[03:11] <BBB> yeah I think I killed it all right?
[03:11] <kierank> yes
[03:11] <BBB> \o/
[03:11] <BBB> hurray
[03:11] <kierank> but i think the main reason from my side (and probably others) is inertia
[03:11] <Daemon404> [02:10] <@BBB> lots of democrats are unhappy with republicans, and vice versa <-- the proper view is that everyone and everything is shit
[03:11] <kierank> (read: laziness)
[03:12] <BBB> Daemon404: thats somewhat overly negative
[03:12] <BBB> if only everyone agreedw tih me, all would be good
[03:12] <Daemon404> seems pretty realistic for US politicians
[03:12] <BBB> agreed *with
[03:13] <Daemon404> why would my views be better
[03:13] <Daemon404> is said everything
[03:13] <Daemon404> i*
[03:14] <Daemon404> anyway what i was getting at, re: forks, the only way to stay sane for the unaffiliated is to give 0 fucks
[03:15] <Daemon404> and that is my stance, and why im not involved in any of the troll threads
[03:16] <jamrial> the inline asm made people not use swr?
[03:17] <kierank> the fact that it looked like swscale did as well
[03:18] <pross-au> jamrial: yes, don't we all read the source code before we use something?
[03:54] <cone-41> ffmpeg.git 03ThomasVolkert 07master:50a4d5cfc674: Add support for H.261 RTP payload format (RFC 4587)
[04:06] <cone-41> ffmpeg.git 03Carl Eugen Hoyos 07master:0744daa887ca: Do not print a useless error number if mov header reading fails.
[04:06] <cone-41> ffmpeg.git 03Carl Eugen Hoyos 07master:6f78c7032479: doc/ffmpeg: Try to clarify that the input option -r is not the same as -framerate.
[04:07] <cone-41> ffmpeg.git 03Carl Eugen Hoyos 07master:7c0c97cc05af: fate: Fix ffprobe tests with --target-path set.
[04:07] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:1aa153d64479: Merge remote-tracking branch 'cehoyos/master'
[11:39] <cone-753> ffmpeg.git 03Michael Niedermayer 07master:2f0f93757735: Changelog: add "H.261 RTP payload format (RFC 4587)"
[11:39] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:1506ea947d3c: pnmenc: use bits_per_raw_sample
[11:52] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:38e2aa3759c6: x86: hevc_mc: correct unneeded use of SSE4 code
[12:10] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:3e892b2bcdb6: x86: hevc_mc: split differently calls
[13:20] <cone-753> ffmpeg.git 03Paul B Mahol 07master:b73b36bfa5ed: avcodec/xan: fix style issue
[13:20] <cone-753> ffmpeg.git 03Paul B Mahol 07master:6dfa70f272d7: Correct few "ffmpeg" typos
[13:41] <ubitux> durandal_1707: 22:24:01 <@Daemon404> someone should have told him it was a trained neural network
[13:41] <ubitux> about the 13M of floats
[13:41] <durandal_1707> i read it from archive
[13:47] <ubitux> ok :)
[13:49] <wm4> 13MB of floats? wut
[13:49] <wm4> is this some insane proprietary codec?
[13:50] <ubitux> a deinterlacing filter
[13:51] <ubitux> wm4: https://github.com/dubhater/vapoursynth-nnedi3 "src/binary1_0.9.4.bin"
[13:51] <wm4> oh, avisynth shit? D:
[13:51] <wm4> ah
[13:51] <wm4> yeah.
[13:51] <ubitux> your favorite filtering project ;)
[13:51] <wm4> apparently that filter is the best shit ever
[13:51] <wm4> just don't look at its source
[13:52] <wm4> the vapoursynth port is probably a lot cleaner
[13:52] <ubitux> "yasm is currently not optional."
[14:04] <ubitux> J_Darnley: no progress on the beat detect? i would love to have that in ffmpeg&
[14:05] <wm4> ubitux: btw. does the server for the proposed API ML really have a significance?
[14:05] <wm4> maybe j-b could host it :)
[14:05] <ubitux> wm4: yeah sure
[14:06] <ubitux> we can give it a try anyway, it wouldn't engage anyone
[14:06] <ubitux> it can be seen as an experiment
[14:09] <ubitux> wm4: does my mail sound like a joke or something?
[14:09] <wm4> no
[14:10] <wm4> I'm glad that a ffmpeg person makes a move towards cooperation
[14:10] <ubitux> wm4: unfortunately, as kierank said, it's probably not a good idea that it comes from one side instead of a neutral party
[14:11] <ubitux> because they might oppose to it just because it comes from a ffmpeg folk
[14:11] <ubitux> we'll see
[14:13] <ubitux> michaelni:
[14:13] <ubitux> remote: -Deny- Tabs found in tests/fate/filter-video.mak.
[14:14] <ubitux> i didn't add any, but there are some tabs there
[14:14] <ubitux> since 706208ef47bffd525c982975d2756f7b2b220b8d i suppose
[14:15] <kurosu> ubitux, out of curiosity, what would be the git few-liner you used to find this ?
[14:15] <ubitux> find out?
[14:16] <ubitux> the tabs?
[14:16] <ubitux> i just tried to push something, the server hook denied me
[14:16] <wm4> gitk is pretty neat for git blaming
[14:17] <ubitux> i generally avoid git blame all together and use git log -p and / in the pager
[14:17] <kurosu> ubitux, no, the offending commit
[14:17] <ubitux> grep '<inserted tab here>' tests/fate/filter-video.mak
[14:17] <ubitux> git log -p tests/fate/filter-video.mak
[14:17] <ubitux> /printf
[14:17] <ubitux> :p
[14:18] <ubitux> git blame would have been more appropriate but well&
[14:19] <michaelni> ubitux, can the tabs be removed ? if not the git hook is under videolans control, that is if we need an additional exception for another fille type
[14:19] <ubitux> not sure
[14:19] <ubitux> Makefiles need tabs
[14:20] <ubitux> maybe the given rule can be moved in a real makefile
[14:20] <ubitux> (not an included .mak)
[14:24] <michaelni> j-b, on the git server, is the exception that allows tabs covering tests/fate/filter-video.mak ? ubitux seems to have had a problem with tabs in that file (see above) (also it seems other .mak files dont cause the problem we have library.mak with tabs)
[14:25] <ubitux> michaelni: the hash i'm mentioning is relatively recent
[14:25] <ubitux> how did you push taht in the merge?
[14:25] <michaelni> just like any other merge or commit
[14:25] <ubitux> maybe the hook is broken and doesn't check merge?
[14:26] <michaelni> it should check the actual changes that a merge introdueces but must not check individual merged commits
[14:27] <michaelni> so that one can remove tabs in the merge commit but they are allowed in individual commits otherwise merging could fail
[14:28] <michaelni> i thought it did that correctly
[14:30] <michaelni> anyway i prefer the lack of a check over one that blocks a good push
[14:34] <michaelni> ubitux, if you tell me what you wanted to push, i could merge it, if that works better
[14:34] <ubitux> ok, just a moment
[14:36] <ubitux> michaelni: https://github.com/ubitux/FFmpeg/compare/codecview
[14:51] <kierank> wm4: you should express your approval
[14:52] <wm4> hm right... you also should
[14:59] <cone-753> ffmpeg.git 03Clément BSsch 07master:f888331769d6: avfilter: add codecview filter
[14:59] <cone-753> ffmpeg.git 03Michael Niedermayer 07master:f155e01ab066: Merge remote-tracking branch 'ubitux/codecview'
[14:59] <ubitux> michaelni: heh, thanks
[15:00] <michaelni> np
[15:07] Action: Daemon404 wonders if ubitux is enjoying the deafening silence wrt his ML thread
[15:08] <ubitux> :)
[15:34] <cone-753> ffmpeg.git 03Carl Eugen Hoyos 07master:cc0acdbd6841: lavc/h264_slice: Add a missing newline to an error message.
[16:08] <durandal_1707> what happened with that yadif patches
[16:15] <nevcairiel> What yadif patches
[16:20] <durandal_1707> from michael
[16:21] <nevcairiel> Because he writes so little patches that I remember every single one of them
[16:24] <durandal_1707> avfilter/yadif experiment #2
[16:28] <nevcairiel> Guess nothing happened
[16:43] <Compnn> were they lost during the lgpl yadif shuffle ?
[18:47] <jamrial> ubitux: your propossal doesn't seem to be popular, judging by Anton's huge API change rfc sent to libav-devel a day after your email
[18:48] <ubitux> well, it's probably it's too soon
[18:48] <ubitux> Anton wasn't going to wait for the mailing-list, that's understandable
[18:57] <wm4> yes, he prepared this stuff a long time ago
[19:13] <jamrial> well, if he's been cooking this for so long then it's not like he couldn't have waited a week if he actually found ubitux's proposal interesting
[19:14] <ubitux> it's not really important :)
[19:14] <ubitux> let's wait a week or two
[19:22] <Compnn> codec > codecpar ? what a bunch of crap. why not just redefine codec in the start of the file once ?
[19:23] <ubitux> huh?
[19:23] <ubitux> Compnn: you can't do that
[19:23] <Compnn> are you sure ?
[19:24] <Compnn> i thought i saw it in another file
[19:24] <ubitux> you're too vague
[19:24] <ubitux> please be specific
[19:24] <Compnn> http://lists.libav.org/pipermail/libav-devel/2014-August/062605.html
[19:24] <wm4> Compnn is clueless as usual
[19:25] <Compnn> changes codec to codecpar
[19:25] <Compnn> isnt it possible to define that at the start of the file instead of changing all of those lines ?
[19:25] <nevcairiel> Leave the code to the coders
[19:25] <nevcairiel> :d
[19:26] <nevcairiel> Although I'm not a fan of the name codecpar
[19:26] <wm4> the name is a bit weird
[19:27] <ubitux> Compnn: it could be possible if codec wasn't accessed from st
[19:27] <ubitux> but here you have no choice
[19:27] <Compnn> ah
[19:27] <ubitux> you can't do st->codecpar = st->codec :p
[19:29] <ubitux> nevcairiel: let's suggest "cp" so it's twisted in several ways
[19:38] <ubitux> lol michael's mail not reaching libav-devel
[19:40] <ubitux> JEEB: :D
[19:40] <JEEB> ;)
[19:41] <ubitux> great minds think alike
[19:41] <wm4> well this is a "who behaves better" game now
[19:42] <wm4> ffmpeg made a step forward
[19:42] <wm4> if Libav doesn't, we can all call Libav stupid
[19:42] <nevcairiel> But we won't, since we're the nice guys now!
[19:45] <ubitux> michaelni: were you able to test it?
[19:46] <ubitux> real hw or qemu?
[19:48] <michaelni> qemu, yes
[19:48] <michaelni> aarch64 swr that is
[19:48] <ubitux> yup ok
[19:49] <michaelni> theres also some resample code left that should be ported, if you or BBB want to do it
[19:54] <jamrial> the most important thing to be ported imo is x86 asm remixing of >2ch
[19:59] <michaelni> jamrial, do you want to work on it / have time ?
[20:00] <michaelni> and about resampling code, i meant aarch64 resampling code
[20:02] <jamrial> not really
[20:04] <michaelni> jamrial, ok, which functions exactly would need porting ?
[20:07] <ubitux> the mix 3..8 to 1..2?
[20:09] <jamrial> yeah
[20:09] <ubitux> 2f096bb10e0584397a08b418fdfa7ecc862ebfa0 ?
[20:11] <jamrial> yes, that one
[20:12] <jamrial> seems to be downmix only, but still really important since 5.1 or 7.1 to stereo is the most common downmix case for users
[20:39] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:c2c4cee86692: avformat/matroskaenc: Check alpha_mode
[21:35] <cone-989> ffmpeg.git 03Luca Barbato 07master:424b929b5cb9: pulse: Add a wallclock option to be compatible with other other captures
[21:35] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:511398031cc9: Merge commit '424b929b5cb9ca4094099f25179829260d4b0fa3'
[21:36] <BBB> resample aarch64 code?
[21:36] <BBB> Im unlikely to care, sadly
[22:17] <ubitux> mmh the altivec code for 8x8 actually does read 16x8
[22:17] <ubitux> that can be problematic
[23:41] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:3fe9e7be4c70: avcodec/utils: add GBRP16 to avcodec_align_dimensions2()
[00:00] --- Mon Aug 25 2014
1
0
[00:00] <SmallMalePony> When I convert a file into a fixed-bitrate audio exact copy with this command: ffmpeg.exe -i %1 -c:a pcm_s16le -q:v 0 %1.avi
[00:00] <SmallMalePony> ... it doesn't have any sound once loaded into Premiere Pro. It does have sound when played in my media player. Any idea why that is? Premiere Pro doesn't give an error of any kind. The video fully works. Just no sound at all.
[00:04] <sacarasc> Does it support PCM?
[00:05] <SmallMalePony> Apparently not.
[00:06] <SmallMalePony> All I'm trying to do is get constant bitrate.
[00:06] <SmallMalePony> So it won't mess up the audio by drifting.
[00:08] <cbsrobot-> SmallMalePony: try to write a video and an audio separately
[00:08] <cbsrobot-> ffmpeg.exe -i %1 -c:a pcm_s16le -vn %1.wav -q:v 0 -an %1.avi
[00:12] <SmallMalePony> cbsrobot-: Trying it now. Will take quite some time.
[01:01] <SmallMalePony> cbsrobot-: Okay. Now it has finished and I have tested it.
[01:01] <SmallMalePony> It STILL produces lagged (drifted) audio in Pre.
[01:01] <SmallMalePony> Grrrr.
[01:01] <SmallMalePony> I HATE that issue.
[01:01] <SmallMalePony> How can that be even with this method?
[01:07] <SmallMalePony> ffmpeg.exe -i %1 -c:a pcm_s16le -vn %1.wav -q:v 0 -an %1.avi
[01:07] <SmallMalePony> Like above.
[01:07] <SmallMalePony> And the output... well...
[01:08] <SmallMalePony> It's long gone, but it was completed.
[03:34] <cbsrobot-> SmallMalePony: just paste the console output of: ffmpeg.exe -i %1
[03:54] <SmallMalePony> I already deleted the file. Sorry.
[06:06] <waressearcher2> in "man ffmpeg" it says: "You can use '-me zero' to speed up motion estimation", but if I use ffmpeg with that option it says: "Unrecognized option 'me'." "Error splitting the argument list: Option not found", so what is that "-me" option ?
[10:08] <Fjorgynn> varsågod
[13:45] <Mavrik> o/
[16:12] <feliwir> hello, does the demuxer provide subtitle stream packages at the correct time?
[16:12] <feliwir> (short before they play)
[22:18] <t4nk580> Hi =)
[22:21] <t4nk580> can someone say me how to "force" a subtitle tu be displayed at the launch of a video ?
[22:37] <Twoll> bof
[22:37] <Twoll> y'a personne
[22:37] <Twoll> t4nk580 :D
[22:46] <pie__> i have mp4 video files from youtube and i only want the audio, how can i strip video from the files?
[22:46] <sacarasc> ffmpeg -i blah.mp4 -vn -sn output.mkv
[22:47] <sacarasc> Or output.mp4 if you want.
[22:47] <pie__> ok thanks, also, any idea if androids media player will do mp4? though i suppose i could just look it up
[22:47] <pie__> and one would think it can
[22:48] <sacarasc> Yes, it will.
[22:48] <pie__> ok thanks :)
[22:49] <t4nk580> do you know for my question sacarasc ? ^^
[22:49] <sacarasc> No.
[22:50] <pie__> sacarasc: is it possible to modify in place?, ie omit the output file name
[22:50] <sacarasc> No.
[22:51] <pie__> im assuming specifying the same name as the input file will break things, i want to iterate over a folder of mp4 files and i was thinking of using find . -exec ... \;
[22:52] <sacarasc> You could output them to a different directory, then move them all in when you're done.
[22:52] <pie__> hm that should work with finds ./filename if i do somehting like otherfolder/./filename
[22:52] <pie__> ah, the problem is i dont have enough disk space :)
[22:52] <pie__> i suppose i could try making some :/
[22:54] <pie__> though all the audio files just might fit in 460mb
[22:57] <pie__> well hopefully this should work
[22:57] <pie__> gonna take a ton of cpu though
[22:57] <sacarasc> No it won't.
[22:57] <sacarasc> ffmpeg -i blah.mp4 -vn -sn -c:a copy output.mkv
[22:57] <sacarasc> I missed a bit.
[22:58] <sacarasc> It will take like no CPU, be 99% IO.
[23:02] <pie__> oh cool :) well one would think so when theres intuitively, no transcoding going on
[23:02] <pie__> but its using almost a full cpu core
[23:03] <pie__> (im on a core 2 duo 6600 or somesuhc)
[23:03] <pie__> or is it possible that simple io is bogging down the cpu like that?
[23:55] <benlieb> dig the new site!
[23:57] <benlieb> is there a way to generically specify end of file with -to ?
[00:00] --- Mon Aug 25 2014
1
0
[01:14] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:585047bb7dae: h264: do not return on sidedata allocation failure
[01:45] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:7444cf9a9c0b: avcodec/imc: Fix bitstream buffer padding
[02:28] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:8231764784a4: ffv1dec: check that global parameters do not change in version 0/1
[02:28] <cone-195> ffmpeg.git 03Luca Barbato 07release/2.2:23376ae2f024: mpegts: Define the section length with a constant
[02:28] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:1578986a0da4: proresenc_kostya: properly account for alpha
[02:28] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:5b1a953960dd: Merge commit '8231764784a405f546e9c427a6de22d3f4de5c35' into release/2.2
[02:29] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:f1da6691a41f: Merge commit '23376ae2f0247ff659724b6a5313639db0c991ad' into release/2.2
[02:42] <cone-195> ffmpeg.git 03Luca Barbato 07release/2.2:7788297a5965: mpegts: Do not try to write a PMT larger than SECTION_SIZE
[02:42] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:afbaf6b367e1: Merge commit '7788297a59656ececd84f602292bfeb79f7eedd7' into release/2.2
[02:58] <cone-195> ffmpeg.git 03Reinhard Tartler 07release/2.2:493a92313fa6: Prepare for 10.4 Release
[02:58] <cone-195> ffmpeg.git 03Reinhard Tartler 07release/2.2:ee9e966296d7: Update Changelog for v10.4
[02:58] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:b3f48a5044fd: proresenc: Remove unneeded parameters from encode_alpha_plane()
[02:58] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:e912b0777b24: proresenc: Report buffer overflow
[02:58] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:9e6d8c309f27: Merge commit 'ee9e966296d74ca3836be5b5adc839cfc73d8c98' into release/2.2
[02:58] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:35fe089dd9b6: Merge commit 'b3f48a5044fd04539337e91d28022207c9d3b9e8' into release/2.2
[02:58] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:459a84ada3b7: Merge commit 'e912b0777b24133df27836b6c529faa89af588dc' into release/2.2
[03:13] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:a437298de55c: proresenc: Realloc if buffer is too small
[03:13] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:f25f5f8c62ec: proresenc: Properly account for alpha plane
[03:13] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:bb1d75e6c5e3: Merge commit 'a437298de55c6a6a4f06b12335b3891bf4459082' into release/2.2
[03:13] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:8b55f67e3ee3: Merge commit 'f25f5f8c62ec7728ee7f5dcc8f1abd0dc6235735' into release/2.2
[03:26] <cone-195> ffmpeg.git 03Diego Biurrun 07release/2.2:37e2d574ddce: setpts: Add missing inttypes.h #include for PRId64
[03:26] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:5ac46a0969a3: Merge commit '37e2d574ddcedc25e32bd963737b033354543789' into release/2.2
[05:03] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:949057c95879: avcodec/h264: do proper cleanup in ff_h264_alloc_tables() in case DPB alloc fails
[05:03] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:1fa35e4352cc: avcodec/h264_slice: More complete cleanup in h264_slice_header_init()
[10:07] <cone-195> ffmpeg.git 03Muhammad Faiz 07master:c82a288f8747: avfilter/showcqt: add fontcolor option
[10:20] <cone-195> ffmpeg.git 03Clément BSsch 07master:45c7f3997ea1: avutil/pixelutils: faster pixelutils_sad_[au]_16x16
[15:29] <cone-195> ffmpeg.git 03Reimar Döffinger 07master:8fc9bd0d32f0: dict.c: Free non-strduped av_dict_set arguments on error.
[15:50] <ubitux> saste: yes, "timecodes" are for a few known fixed rates
[15:50] <ubitux> saste: it's a SMPTE timecode, some broadcast stuff
[15:51] <ubitux> it's just a representation of frame number as a time bastardization for humans
[15:51] <ubitux> you're not supposed to use it unless you know what you are doing
[15:55] <saste> ubitux, uhm ok
[15:55] <saste> i need to show PTS representing a time, which is different from the PTS time
[15:56] <saste> so I need to add an offset
[15:56] <saste> i could do setpts,drawtext,setpts
[15:56] <saste> but maybe I could add an offset parameter to the %{pts} function
[15:56] <ubitux> i thought we had such thing
[15:57] <saste> with timecodes it is possible to set the initial value
[15:57] <ubitux> mmh maybe that was just %{pts} indeed
[15:57] <ubitux> would be nice to have a timed representation indeed
[15:58] <ubitux> saste: it seems possible
[15:58] <saste> what do you mean by "timed representation"?
[15:58] <ubitux> there is a "hms" mode for func_pts
[15:59] <saste> The second argument is an offset added to the timestamp.
[15:59] <saste> wtf i missed that...
[15:59] <ubitux> %{pts:hms}, right
[16:00] <ubitux> we should add an example in the documentation
[16:02] <ubitux> we don't have a boxpadding option btw?
[16:08] <cone-195> ffmpeg.git 03Clément BSsch 07master:f4dec0dba0fa: doc/filters: fix Shwo/Show typo
[19:04] <wm4> ubitux: hm the more I think about this, the more I'm convinced that subtitle converters absolutely do not belong in libavcodec
[19:05] <kierank> smarter: http://www.slideshare.net/fullscreen/touradj_ebrahimi/spie2014-hev-cvsvp9/
[19:05] <wm4> the converters seem to be the only decoders which must access AVPacket pts/duration, while normally no decoder needs to interpret these fields (and also don't need a time_base)
[19:19] <ubitux> wm4: the reason they need it is because the internal ass representation need that
[19:20] <ubitux> what is wrong is the internal ass representation
[19:20] <ubitux> when we drop that, the decoders will no longer require it
[19:26] <ubitux> i guess i'm going to go back on subtitles again soon
[19:34] <Compn> ubitux : we could just do it both ways
[19:34] <Compn> internal ass and external filters to convert it or whatever
[19:36] <ubitux> Compn: internal ass is wrong, we need to change its form because the timestamps don't belong here
[19:37] <ubitux> i don't get what you mean about "external filters"
[20:14] <cone-637> ffmpeg.git 03Clément BSsch 07master:554d8190624f: avutil/pixelutils: faster pixelutils_sad_16x16
[20:16] <ubitux> anyone with ppc hw here?
[20:18] <ubitux> with altivec in particular
[20:18] Action: cbsrobot- stares at his basement
[20:19] <wm4> ubitux: unfortunately, the "other" ass subtitle format has this problem that it requires a sequence number
[20:20] <ubitux> yes
[20:20] <ubitux> that's why we will probably come up with a different representation than ass
[20:20] <ubitux> without these constraints
[20:22] <wm4> the fabled universal tag format?
[20:22] <ubitux> for example, or simply a bastardization of ass
[20:23] <wm4> the latter sounds potentially better
[20:23] <ubitux> "ffass"
[20:23] <ubitux> maybe "ffatass" sounds better
[20:23] <wm4> "assff"
[20:24] <ubitux> "aff" ?
[21:30] <BtbN> Is there some high motion lossless video i can use for encoder testing somewhere?
[21:41] <durandal_1707> anybody going to port nnedi3?
[21:42] <ubitux> BtbN: maybe some scenes of tears of seal or sintel?
[21:42] <ubitux> durandal_1707: not me
[21:43] <ubitux> durandal_1707: https://github.com/dubhater/vapoursynth-nnedi3 right?
[21:43] <durandal_1707> yes
[21:56] <kurosu> "binary1_0.9.4.bin"
[21:57] <Compnn> michaelni : another great mail about the differences of review and commits to ffmpeg and merges from libav. thank you for not flaming with atilla :)
[22:00] <ubitux> kurosu: 13M of weird float tables? :D
[22:01] <ubitux> durandal_1707: hf porting this..
[22:01] <Compnn> BtbN : foreman ?
[22:01] <durandal_1707> ubitux: hf?
[22:01] <ubitux> have fun
[22:01] <BtbN> Compnn, hm?
[22:02] <durandal_1707> ubitux: i dont get what function actually do work
[22:03] <durandal_1707> shit what this .bin thing do
[22:04] <ubitux> it's 13M of floats
[22:04] <ubitux> :D
[22:04] <durandal_1707> 13M ??? that is insane
[22:06] <cone-637> ffmpeg.git 03Luca Barbato 07master:f9f34cb9983e: ogg: Use separate classes for the aliases
[22:06] <cone-637> ffmpeg.git 03Michael Niedermayer 07master:9bff8cfc913e: Merge commit 'f9f34cb9983ec6f4ef119c34b726d3b39c143110'
[22:22] <cone-637> ffmpeg.git 03Reinhard Tartler 07master:5caf039ba2b4: Prepare for 11_beta2 Release
[22:22] <cone-637> ffmpeg.git 03Michael Niedermayer 07master:e3601ceeb875: Merge commit '5caf039ba2b4be067568a30146f29008d8db28d0'
[22:23] <Daemon404> oh he left
[22:24] <Daemon404> someone should have told him it was a trained neural network
[22:33] <Compnn> BtbN : http://samples.ffmpeg.org/yuv/foreman.qcif.bz2 lossless raw motion
[22:33] <BtbN> ah, nice. Thanks
[22:33] <Compnn> theres other clips in that dir
[22:34] <Compnn> i dunno which is best...
[22:59] <cone-637> ffmpeg.git 03Reinhard Tartler 07master:749b1f1359b5: configure: add --enable-rpath
[22:59] <cone-637> ffmpeg.git 03Michael Niedermayer 07master:2e3c1699aea7: Merge commit '749b1f1359b5af0a08221923b016551b18ab6171'
[23:03] <BBB> BtbN: typically people use https://media.xiph.org/video/derf/
[23:03] <BBB> BtbN: theres also some more academic collection used for hevc/h264, but I dont know if theres a single location for it
[23:04] <BtbN> Yeah, i already got what i needed
[23:04] <BBB> ok cool
[23:06] <BtbN> Couldn't get ShadowPlay to just encode a random video anyway. So i had to play a random FPS game and compare that.
[23:26] <ubitux> kierank: why are you so pushy about having michael moving to VDD :/
[23:26] <ubitux> it won't make a single (positive) difference
[23:29] <kierank> i am not the only one
[23:29] <kierank> see j-b's email
[23:30] <kierank> ubitux: it can't make the situation worse
[23:30] <ubitux> it can
[23:30] <ubitux> definitely
[23:30] <kierank> how can it get worse than now
[23:31] <ubitux> people can be manipulated easily in such situation
[23:32] <ubitux> also, as i already explained several times, what will be said and how it will be remembered are two different things
[23:32] <ubitux> and there will be no trace except random testimonies
[23:32] <ubitux> testimony*
[23:33] <ubitux> Stefano didn't approve this harassment either btw
[23:33] <kierank> neither did carl
[23:33] <kierank> but the part in these emails saying I'd love to have a discussion with you etc etc
[23:33] <kierank> but then not doing anything is a joke
[23:34] <ubitux> discussion can be over email and irc
[23:34] <kierank> you think there hasn't been enough of that with libav
[23:35] <ubitux> then how changing the medium will change anything?
[23:35] <kierank> because it is conducive to compromise
[23:36] <ubitux> this is insane
[23:36] <ubitux> it's like saying "let's make a compromise; we agree on the technical part, and on your side please hit your head on a wall so we are even"
[23:37] <kierank> so turning up to have an adult conversation is "hitting your head on the wall
[23:38] <ubitux> no, but forcing someone physically move just for the sake of having him move around the globe is definitely not behaving as an adult
[23:38] <ubitux> real life talks are broken to talk about such issues
[23:38] <ubitux> and i explained why
[23:38] <kierank> let's be honest even if we held the meeting in vienna at his house he wouldn't do anything
[23:39] <kierank> sorry to talk about someone here in the 3rd person
[23:40] <ubitux> and so what?
[23:40] <kierank> see all of j-b's email as response
[23:40] <ubitux> see mine
[23:41] <kierank> the world is bigger than ffmpeg and libav's petty fight
[23:41] <kierank> everyone has to deal with the mess as a result because some people are to petty to talk
[23:41] <kierank> i hope he forks to be honest
[23:41] <ubitux> the world can learn to send emails
[23:42] <kierank> yeah because the one thing we want more of is hearing the same stories for the 20th time
[23:42] <kierank> with each side's sprinkle of BS on top
[23:42] <ubitux> yes, and ofc in real life it will make a huge difference
[23:43] <kierank> libav people will speak to michael irl
[23:43] <kierank> but not by email
[23:43] <ubitux> if you expect michael to say different things in real life, then maybe that's because you expect to influence him in some way
[23:43] <kierank> carl on the other hand
[23:43] <kierank> by definition compromise involves changing your position
[23:43] <kierank> so yes
[23:43] <kierank> I hope positions on both sides will move
[23:44] <ubitux> and what so changes do you suggest?
[23:44] <kierank> I can't read minds
[23:45] <ubitux> i'm sure libav can make a list
[23:45] <kierank> and you can make a list for them
[23:45] <ubitux> yes
[23:45] <ubitux> we can make our own, but we don't have much requests
[23:46] <kierank> what about the users
[23:46] <kierank> again going back to this petty problem
[23:46] <kierank> the world is bigger than ffmpeg/libav
[23:46] <ubitux> we communicate with our users through mailings lists and irc; also, we have ffmpeg representative at these meetings
[23:47] <ubitux> we don't need to have michael their if he is not willing to go
[23:47] <ubitux> there*
[23:47] <kierank> your users (cf debian-devel) want you to stop fighting
[23:47] <ubitux> we are not fighting
[23:47] <kierank> michael's (perceived or past or current or whatever) behaviour is a major issue in the ffmpeg/libav split
[23:47] <kierank> therefore michael is involved
[23:48] <ubitux> no such complain was raised in the thread except from libav ppl digging 3yrs old threads
[23:48] <kierank> huh
[23:48] <kierank> look at all the people saying how they have to rewrite their code because of forks
[23:48] <ubitux> how is that directed at michael?
[23:49] <ubitux> it's a fork issue, not "a michael issue"
[23:49] <ubitux> we do our best on the technical part to fix that
[23:49] <kierank> if there was no fork the problem would not exist and michael is a part of the forking reasons
[23:49] <ubitux> he was 3yrs ago
[23:50] <kierank> sure but libav people don't see anything else apart from that
[23:50] <kierank> except for misleading posts on debian-devel
[23:50] <kierank> which makes the situation worse
[23:50] <kierank> and no concept of compromise
[23:50] <ubitux> the compromise is to not replace libav
[23:51] <kierank> "if you come to ffmpeg and delete avresample we can all work happily " (lol)
[23:52] <ubitux> kierank: we can listen to suggestions to change our workflow
[23:52] <ubitux> actually, wm4 raised the topic a few days ago
[23:52] <ubitux> about the technical changes
[23:52] <ubitux> it was frozen on both side
[23:53] <ubitux> (we don't agree on the review process)
[23:53] <kierank> sure you don't agree on the review rules but you could come to some agreement where there is a mailing list where both sets of patches go to
[23:53] <kierank> on a neutral domain
[23:53] <kierank> so that ffmpeg people can comment on libav changes
[23:54] <kierank> like me you probably need to filter out the term k&r
[23:54] <kierank> but anyhow
[23:54] <ubitux> we could setup an automatic forward to such list
[23:54] <kierank> yes but has there been any proposals between both sides?
[23:54] <kierank> no
[23:54] <ubitux> or actually, you would just have to register ffmpeg-devel and libav-devel to a common ml
[23:54] <kierank> because both sides have never communicate
[23:55] <ubitux> well& what do you want to communicate about?
[23:55] <ubitux> i mean, we do communicate at times
[23:55] <kierank> setting up such a list for example
[23:55] <kierank> and to be honest on the neutral mailing list nobody can say on either side that someone is a spy or other nonsense
[23:56] <ubitux> but everytime i point out something from ffmpeg on libav side i get either ignored or some ppl say to me that i'm permanently trying to show ffmpeg is better
[23:56] <iive> there was "bringing ffmpeg and libav closer" thread a few months back.
[23:56] <kierank> ubitux: yes so on the neutral mailing list it is better
[23:56] <ubitux> sure ok
[23:56] <ubitux> well then
[23:56] <ubitux> let's just setup such ml
[23:56] <iive> then I demanded that michaelni ban is removed from their maillist, as a sign of good will
[23:57] <ubitux> and register {ffmpeg,libav}-devel to it
[23:57] <kierank> ubitux: so you contact all libav and ffmpeg people
[23:57] <ubitux> i see no problem with that
[23:57] <kierank> to notify them and discuss the issue
[23:57] <kierank> ...
[23:57] <kierank> this is what discussing things in person is good for
[23:57] <ubitux> how would that help?
[23:57] <ubitux> i can send a mail to both ml if you want (but :effort:)
[23:57] <kierank> you're basically proving my point here
[23:58] <ubitux> i wouldn't have the courage to even participate in such talk in real life
[23:58] <ubitux> i'd avoid the thing
[23:58] <Case> why do some people care about libav at all?
[23:58] <kierank> because by some definition it is ffmpeg upstream
[23:58] <kierank> and controls much of the api
[23:58] <ubitux> because it's packaged on debian
[23:58] <ubitux> and so users need to support both
[23:59] <Case> debian needs to nuke it asap
[23:59] <iive> sure
[23:59] <ubitux> it doesn't need to nuke libav
[23:59] <iive> do you know a debian ftp master?
[23:59] <ubitux> really that's not what we are trying to achieve here
[23:59] <kierank> 10:58 PM <"ubitux> i wouldn't have the courage to even participate in such talk in real life --> on the mailing list you even said you talked with libav poeple
[23:59] <Case> no because michael is too kind
[00:00] --- Sun Aug 24 2014
1
0
[01:00] <rjp421> can i use a multibitrate .f4m/.m3u8 as an input and expect the adaptive bitrate switching to work?
[05:06] <SmallMalePony> When I convert a file into a fixed-bitrate audio exact copy with this command: ffmpeg.exe -i %1 -c:a pcm_s16le -q:v 0 %1.avi
[05:06] <SmallMalePony> ... it doesn't have any sound once loaded into Premiere Pro.
[05:06] <SmallMalePony> It does have sound when played in my media player.
[05:06] <SmallMalePony> Any idea why that is?
[05:06] <SmallMalePony> Premiere Pro doesn't give an error of any kind. The video fully works. Just no sound at all.
[06:14] <ecaz> Does FFmpeg stream / rip SACD in linux?
[06:14] <ecaz> audio
[09:39] <djdduty> hey guys, I am trying to use cli ffmpeg on windows, and I have a bunch of images name '1.png' all the way up to like '2201.png', am wanting to compile them via ffmpeg into a timelapse video, however using '%d.png' or similair says no files found, how can I get it to work without adding 0s to make the all the same number of chars long and using %5d.png or whaever that is.
[09:39] <djdduty> I have done it before, and completely forgotten
[09:40] <relaxed> djdduty: ffmpeg -f image2 -pattern_type glob -r $framerate -i *.png ...
[09:41] <relaxed> or just %d.png should work
[09:41] <djdduty> relaxed: I have tried both of those...
[09:41] <djdduty> relaxed: oh wait, I made progress
[09:41] <djdduty> need to specify an output file...
[09:42] <djdduty> thought my command was solid, I guess not
[09:43] <djdduty> there we go... relaxed I got it, I didn't notice I had ' around the file name.
[09:43] <relaxed> it was liquid
[09:49] <anshul_mahe> I have webcam working on linux and on windows with other webcam software
[09:49] <anshul_mahe> but in windows using ffmpeg it fails like this http://pastebin.com/NPpcqrX0
[09:50] <anshul_mahe> I am using ffmpeg cmd on windows
[10:10] <drag0nius> how can i get file info without ffmpeg throwing At least one output file must be specified ?
[10:14] <anshul_mahe> drag0nius, you can use ffprobe, it gives file info and does not throw error
[10:14] <drag0nius> thanks
[10:15] <anshul_mahe> I am using windows webcam dshow ffmpeg, ffmpeg does list the device but when i try to dump the webcam stream dshow give no device found
[10:16] <anshul_mahe> for detail of command http://pastebin.com/CnqECd19
[11:33] <js3> hey guys
[11:33] <js3> is there someway to demux a file with ffmpeg
[11:34] <js3> i want to demux the audio, encode it with another app, use ffmpeg and libx264 to encode the video
[11:34] <js3> then mux them back together again
[11:34] <js3> but i can't figure out how to demux
[11:41] <c_14> ffmpeg -i input -vn -c:a copy out.audio
[11:49] <js3> thanks :)
[11:49] <js3> c_14 so i run this
[11:49] <js3> ffmpeg -i input -vn -c:a copy out.audio
[11:50] <js3> encode the audio with besweet
[11:50] <onto> Hi! I am trying to convert a sequence of pngs from stdout and convert them to a video file with the following: "./frameserve | ffmpeg -y -c:v png -f image2pipe -r 10 -sameq -i - -c:v libx264 -pix_fmt yuv420p test.mp4" but it keeps showing "Error while decoding stream #0:0"
[11:50] <js3> then my line is like this
[11:50] <onto> I'm using: ffmpeg version 0.10.12-7:0.10.12-1~precise1
[11:50] <js3> ffmpeg.exe -y -i %input% -sws_flags spline -sn -vf yadif=1:0,crop=%width%:%height%:%left%:%top% -s 704x394 -c:v libx264 -preset slow -crf %crf% -r 50 %output%.mp4
[11:51] <js3> how can i remux the audio in that line
[11:52] <js3> or on a seperate line
[11:58] <relaxed> onto: remove -sameq
[11:58] <relaxed> onto: Oh, you need to upgrade.
[11:59] <onto> relaxed: I tried removing sameq, will try upgrading
[11:59] <relaxed> the current version is 2.3.3
[11:59] <relaxed> http://johnvansickle.com/ffmpeg/
[12:00] <c_14> js3: just add -i %audio%, you might need an appropriate map though
[12:02] <onto> relaxed: Thanks a lot! It's working flawlessly! :)
[12:03] <relaxed> flawless victory
[12:03] <js3> thanks for the help c_14
[12:04] <onto> relaxed: Although, when I terminate the program with "Ctrl+C" it says: "pipe:: Input/output error"
[12:05] <relaxed> so?
[12:05] <onto> relaxed: and the output file doesn't seem to play
[12:05] <relaxed> use "killall -INT ffmpeg" to stop ffmpeg
[12:06] <onto> relaxed: ok, will try. Thanks again!
[12:06] <relaxed> or ffmpeg -i input -t $time
[14:22] <mosasaur> I get Failed to set value 'srt' for option 'codec:s:0.2'
[14:22] <mosasaur> how can I check for subtitle codecs?
[14:24] <mosasaur> "ffmpeg -codecs | grep srt" gives: "D S srt SubRip subtitle"
[14:42] <klaxa> D means decode
[14:42] <klaxa> if it doesn't have an E you can't encode to that format
[14:45] <mosasaur> Thanks klaxa. I got this command from a websearch: "ffmpeg -i *.mp4 -vn -an -codec:s:0.2 srt sub.srt" so it probably worked for them. Can I get a better ffmpeg version?
[14:45] <mosasaur> I'm now using : ffmpeg version 0.8.15-6:0.8.15-1, Copyright (c) 2000-2014 the Libav developers
[14:45] <mosasaur> built on Aug 9 2014 10:19:49 with gcc 4.7.2
[14:49] <klaxa> that is... pretty old, also >libav developers
[14:52] <mosasaur> thanks klax and fflogger, I guess I'll have to compile my own version
[15:38] <mosasaur> OK I compiled and installed ffmpeg and it doesn't produce an error when I extract subs. However the media file uses mov-text and I want to extract to srt. How do I do that? "ffmpeg -i *.mp4 -vn -an -codec:s:0:2 mov_text sub.srt" produces an empty file and says "... Invalid argument"
[15:43] <mosasaur> "ffmpeg -i *.mp4 -vn -an -codec:s:0:2 srt sub.srt" works but only gives 188 bytes
[15:44] <Mavrik> perhaps -f srt?
[15:47] <mosasaur> thanks Mavrik, but the result is the same, somehow I can't get at the data
[15:58] <mosasaur> nvm. I suppose I have the same problem as this : http://stackoverflow.com/questions/20676906/is-it-possible-to-extract-subri… so it would need OCR to extract the subs
[16:39] <SmallMalePony> When I convert a file into a fixed-bitrate audio exact copy with this command: ffmpeg.exe -i %1 -c:a pcm_s16le -q:v 0 %1.avi
[16:39] <SmallMalePony> ... it doesn't have any sound once loaded into Premiere Pro.
[16:39] <SmallMalePony> It does have sound when played in my media player.
[16:39] <SmallMalePony> Any idea why that is?
[16:39] <SmallMalePony> Premiere Pro doesn't give an error of any kind. The video fully works. Just no sound at all.
[19:55] <anshul_mahe> is there any example for avdevice_list_devices or some document about that
[22:25] <notwist> Hey guys, trying to compile, no idea what I'm doing basically but I get "ERROR: libx264 not found" even though it should be available (I compiled it successfully five minutes ago, at least I think so). Here's my config.log: http://paste.ubuntu.com/8125090/
[22:26] <sacarasc> notwist: Can you paste your full command and output.
[22:27] <Chaz6> notwist: I think you're missing a -ldl in there
[22:27] <notwist> full command and output: http://paste.ubuntu.com/8125125/
[22:27] <Chaz6> try LDFLAGS=-ldl configure [...] (iirc)
[22:28] <sacarasc> notwist: Oh, configure isn't finding libx264?
[22:28] <notwist> Chaz6: like this? $ LDFLAGS=-ldl ./configure --enable-gpl
[22:28] <Chaz6> yep like that
[22:28] <notwist> sacarasc: doesn't look like it, no
[22:28] <notwist> Chaz6: got the exact same error
[22:30] <notwist> any way to verify the lib is there to begin with?
[22:30] <Chaz6> might be ./configure --extra-ldflags="-ldl"
[22:30] <Chaz6> It's finding the x264 lib but it's the missing dl that's the problem
[22:31] <notwist> I just did $ ./configure --extra-ldflags="-ldl" --enable-gpl (...) and it's giving me the same error
[22:32] <sacarasc> notwist: Try following this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[22:33] <sacarasc> (And if you did, you installed stuff in the wrong place.)
[22:33] <Chaz6> notwist: you have the same problem as this guy http://comments.gmane.org/gmane.comp.video.ffmpeg.user/48639
[22:33] <notwist> probably should have done that from the start rather than reading some random blog post
[22:37] <notwist> all right, well I'm in way over my head here. I'll just try the guide above some other day. If anyone's interested this is the one I followed: http://www.tedsimbajon.com/Blog/TechBlogExploded.php?id=85 but I elected to use yasm 1.3 instead of 1.2, not sure if that made a difference or not.
[00:00] --- Sun Aug 24 2014
1
0
[01:26] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:fccd85b9f305: avcodec: fix aac/ac3 parser bitstream buffer size
[02:02] <rcombs> what's AVCodecContext::coded_frame for?
[02:10] <iive> avcodec.h contains some documentation
[02:10] <iive> my guess would be that this is the video frame picture
[02:11] <iive> as it is encoded. the encoder need to decode the picture in order to knows how it would look to the decoder.
[02:12] <iive> e.g. you encode video, you put very bad quality. this contains the picture but looking blocky and ugly, because of compression artifacts.
[02:14] <rcombs> most encoders seem to allocate it once, free it when closed, and set a few parameters on it when encoding frames
[02:17] <iive> if it is decoded encoder output, then it should be allocated by get_buffer and be kept for reference.
[02:18] <iive> well, somebody else might know.
[02:18] <iive> i'm off.
[02:45] <wm4> rcombs: many things in ffmpeg are due to legacy reasons; for advance use you pretty much have to use the official ffmpeg code inspection tool (the tool is called "grep" and you use it on source files)
[02:46] <wm4> then you try to make sense out of it and then you fail, and then you don't care
[02:46] <wm4> it's simple
[02:46] <cone-718> ffmpeg.git 03Michael Niedermayer 07master:1b5ec6a0c330: avcodec/fic: Check if a frame is available before using it
[02:48] <rcombs> wm4: that's what I tried to do, and determined that it probably wasn't important but might be slightly useful
[02:48] <rcombs> and figured I'd ask
[02:51] <wm4> basically I'm saying that the docs are bad/incomplete, and it's not surprising if you dig out something that doesn't seem to have much purpose
[04:05] <Timothy_Gu> Finally, I'm back
[04:05] <Timothy_Gu> Any more reviews for the makeinfo stuff?
[06:10] <jamrial> kurosu: just saw your pextrd patch in github. did you bench it?
[06:10] <jamrial> I tried the same in hevc_deblock, and pextrd didn't seem faster than a pshufd + movd there
[06:13] <jamrial> same way i tried replacing a movq + punpcklbw with a pmovzxbw, and the latter was in fact slightly slower, somehow
[06:20] <fionag> yeah, pextrd is 1 shuffle uop + a store
[06:20] <fionag> it's not going to be better than a shuffle + store, in my experience
[06:27] <jamrial> what about pmovzxbw? intel docs mention it's 1 cycle latency, same as a punpcklbw, yet somehow it was slower than the latter + a movq
[06:29] <fionag> well I don'tthink it could be -faster-, because it's a load uop + shuffle uop
[06:29] <fionag> just like movq + punpck
[06:30] <fionag> pengvado's theory if I remember it right was that pmovzxbw required the load and shuffle uops to be more tightly coupled (like e.g. in the same cycle) making out of order execution less effective
[06:30] <fionag> but I think that was relatively wild speculation, nobody really knew why it was slower :<
[07:51] <kurosu> jamrial, exactly, hence why I didn't submit it at all
[07:52] <kurosu> In fact everything there that hasn't been submitted is kind of a failure / useless
[07:52] <jamrial> ah ok
[07:53] <kurosu> well, not failure, but yes, not "benchmarkably" useful
[07:55] <kurosu> I think some of the gprs used as temporary storage could have improved usage with proper shuffling & co
[07:55] <kurosu> but seeing this, I bet it won't have much an impact
[07:56] <kurosu> *the gprs used in the dbf code
[08:01] <kurosu> I'd really like to move on with that mc code
[08:02] <kurosu> I'm planning on "retagging" most functions from sse4 to ssse3, but I don't want conflicts on that work
[12:28] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:ddad09397247: wavpackenc: fix number of samples per block
[12:43] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:e32eddaa51ad: wavpackenc: make assert more thorough
[13:22] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:fb1a98ec5b4e: x86: hevc_mc: assume 2nd source stride is 64
[14:16] <Compn> llogan : so are you back now ? should i stop moderating queue of ffmpeg-devel ?
[14:25] <wm4> does it need much moderation?
[14:57] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:b9f3912a65ac: hevc: move MAX_PB_SIZE declaration
[15:00] <Compn> wm4 : people postin who arent subscribed
[15:01] <Compn> like 1-3 a week, depending on how many flames are at cc'd lists like deb-devel :
[15:02] <wm4> oh I see, that debian flame must generate lots of emails from unregistered people
[15:02] <nevcairiel> it seemed to have moved off-list now
[15:02] <Compn> yes
[15:02] <nevcairiel> or noone approves them anymore
[15:02] <Compn> but also there are lots of patches from random people who arent subscribed
[15:02] <Compn> i've been approving them, and no, there are less mails now.
[15:03] <Compn> possibly because my strategy of asking ffmpeg devs to not reply to flames worked
[15:21] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:d4f44b66d36c: hevcdsp: remove compilation-time-fixed parameter
[15:25] <kierank> wm4: the best bit is that the libav responses don't cc to ffmpeg-devel
[15:25] <kierank> even though the rest of the thread is
[15:26] <wm4> huh
[15:26] <wm4> guess I'm missing the juicy bits of the thread then
[15:26] <kierank> i gave up tracking the threa
[15:27] <ubitux> you'd better watch https://lists.debian.org/debian-devel/2014/08/ than ffmpeg-devel yes
[15:27] <kierank> probably should have responded to luca's nonsense in the name of balance
[15:27] <kierank> but ubitux mostly di that
[15:27] <ubitux> but not really interesting
[15:28] <Compn> no way, let luca's nonsense sit there
[15:28] <Compn> it looks bad on him
[15:28] <kierank> there was nonsense from michael as well
[15:28] <kierank> mans was an author of swresample you know
[15:30] <Compn> i didnt know that. i guess i didnt really look into who wrote what
[15:31] <Compn> i know mans wrote a lot of fate stuff
[15:31] <ubitux> it seems there are still a lot of demand on dumping vobsubs
[15:31] <ubitux> :(
[15:31] <Compn> lol @ mpv
[15:31] <ubitux> saste: made up your mind on dvd support?
[15:33] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:dad7f155678f: hevcdsp: remove more instances of compile-time-fixed parameters
[15:36] <michaelni> kierank, yes mans is AFAIK the author of some code that is in libswresample
[15:36] <michaelni> some arm code to be more precisse
[15:37] <kierank> see my response to that thread
[15:38] <Compn> oh apparently i've missed quite a few mails from deb-devel.
[15:38] <Compn> dang my broken eyeballs
[15:43] <Compn> i like this mail in particular https://lists.debian.org/debian-devel/2014/08/msg00760.html
[15:49] <wm4> those are some juicy emails
[15:54] <wm4> this flame war is like kuwait all over again
[16:09] <ubitux> swr_convert_frame() is untested?
[16:17] <michaelni> ubitux, the avframe related swr stuff isnt tested no, i wanted to add some code to test it but had too many other things to do
[16:17] <michaelni> feel free to add code to test it
[16:17] <ubitux> i was looking for an example in particular, not really important
[16:19] <kurosu> michaelni, what do you think about my comments in "[PATCH] h264: Move AFD to side data to match MPEG-2" ?
[16:19] <kurosu> it's probably work for little to no benefit
[16:19] <kurosu> but I was thinking of sending patches to do what I describe if there's any merit
[16:33] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:2346f2b5db59: x86: hevcdsp: use compilation-time-fixed constant
[16:38] <michaelni> kurosu, maybe the side data code could be left where it is but instead of hard failing would just print a warning. failure to create these sidedata does not appear fatal to me
[16:39] <kurosu> ok, make sense, although an allocation failure is a bad sign at this point
[16:39] <michaelni> yes
[16:39] <kurosu> *it makes sense
[16:43] <kurosu> on the other hand, some users would prefer it to explode rather than go on
[16:44] <kurosu> using "h->avctx->err_recognition & AV_EF_EXPLODE" doesn't make sense here I guess
[16:44] <Daemon404> g 48
[16:44] <Daemon404> woops
[17:23] <saste> ubitux, uhmm...
[17:23] <ubitux> :)
[17:24] <saste> ubitux, i won't have much time for that
[17:24] <saste> ubitux, BTW did you do something about scripting?
[17:25] <ubitux> yes, but my interest drifted to something else
[17:25] <ubitux> sorry :)
[17:27] <saste> ubitux, you don't have to be sorry
[17:27] <saste> i wonder what was the last relevant thing I did for ffmpeg...
[17:28] <ubitux> cb0524f7a02f910ae2df163e655cb495ea9f2493
[17:29] <ubitux> :s
[17:30] <ubitux> saste: i don't do much relevant things either you know :)
[17:30] <ubitux> you actually fix more tickets than i do
[17:31] <saste> yeah i liked that commit :-D
[17:31] <saste> ubitux, did you already commit codecview?
[17:31] <ubitux> i'll do tonight
[17:31] <ubitux> i might add the test at the same time too
[17:33] <ubitux> i also have some pixelutils stuff pending
[17:54] <nexus_6> Hi I've playing with a patch posted on the mailing list that enables hds demuxing: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154612.html
[17:55] <nexus_6> and I have made some modifications to make it work with some hds live streams
[17:55] <nexus_6> particularly hds streams from rte televsion http://livehds.rasset.ie/hds-live/_definst_/rte1/rte1_288p.f4m
[17:56] <nexus_6> should I post this modified patch to the mailing list or should I contact the original author
[17:56] <nexus_6> thanks
[17:57] <ubitux> was that patch applied?
[17:57] <nexus_6> no
[17:58] <ubitux> mmh, maybe you can contact the author first, but if he doesn't reply, i guess you can just cherry-pick his patch, add yours on top, and resend both
[17:58] <ubitux> (or merge them and use signed-off to add your authorship)
[17:58] <ubitux> s/merge/squash/
[17:58] <nexus_6> ok thanks for the info
[18:20] Action: durandal_1707 forces himself to not send K&R patches
[18:49] <cone-195> ffmpeg.git 03Diego Biurrun 07master:b0bfd09f88da: configure: Suppress "potentially uninitialized variable" warnings from MSVC
[18:49] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:de9e0386b2f0: Merge commit 'b0bfd09f88da8b7c7666faf0ac7d5e74559dba9f'
[18:53] <Compn> cool hds support
[18:57] <cone-195> ffmpeg.git 03Janne Grunau 07master:dc4b2e7d3390: rv34: use ff_mpeg_update_thread_context only when decoder is fully initialized
[18:58] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:e356f6c55d46: Merge commit 'dc4b2e7d33903a6b9380e8a84b22b3a20facbb08'
[19:08] <cone-195> ffmpeg.git 03Anton Khirnov 07master:4d6c5152849e: electronicarts: do not fail on zero-sized chunks
[19:08] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:350dd8534575: Merge commit '4d6c5152849e23a4cc0f6a6ac2880c01ebcd301b'
[19:27] <saste> ubitux, timecode display in drawtext only works if you have constant framerate, right?
[19:28] <saste> since the timecode context is configured with a fixed rate
[19:28] <saste> what if you have erratic timestamps?
[19:29] <saste> that is frame PTSs not at regular intervals
[20:47] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:a59f85d1064d: wavpack: check number of channels
[20:47] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:4adad5a19ac8: wavpackenc: reset trailer info on block encoding
[20:59] <cone-195> ffmpeg.git 03Anton Khirnov 07master:7b6aae23e12f: electronicarts: read the framerate for MAD
[20:59] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:ce1059d5c909: Merge commit '7b6aae23e12f41cdfac7f1069debfe44d9a3d136'
[21:06] <cone-195> ffmpeg.git 03Anton Khirnov 07master:cb7b1a2dfb54: electronicarts: set the framerate for TGQ/TQI
[21:06] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:3e07a056a8e6: Merge commit 'cb7b1a2dfb547ab78342a7a9d5cd729d77d90421'
[21:48] <cone-195> ffmpeg.git 03Luca Barbato 07master:051aadeed104: ogg: Provide aliases for Speex, Opus and audio-only ogg
[21:48] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:300d489ac9bb: Merge commit '051aadeed104ecbe8ee4850ec2d7e5394f5e1ccd'
[21:55] <cone-195> ffmpeg.git 03Diego Biurrun 07master:1019b7c4edff: os_support: Undefine lseek/stat/fstat before defining them
[21:55] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:8f3caf52fc0d: Merge commit '1019b7c4edff537499c4a6cb0d65abae04ce58f6'
[22:02] <cone-195> ffmpeg.git 03Diego Biurrun 07master:3526ab891c28: qt-faststart: Undefine fseeko/ftello before defining them
[22:02] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:d2a06242966d: Merge commit '3526ab891c28396ada8b58bf7647309bab30de1d'
[22:29] <cone-195> ffmpeg.git 03Timothy Gu 07master:6e51e746c426: vidstab*: Remove accidentally exported av_2_vs_pixel_format()
[22:29] <cone-195> ffmpeg.git 03Timothy Gu 07master:8495c6086d04: vidstabutils: improve documentation
[23:53] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:aaaf7261b707: avcodec/hevc_ps: fix 1 vs. 0 typo
[00:00] --- Sat Aug 23 2014
1
0
[00:00] <vlatkozelka> http://pastebin.com/pRWBaSad
[00:00] <vlatkozelka> i also tried -use_wallclock_as_timestamps since its a live stream ... still no luck
[01:11] <rjp421> c_14, ah ok ty, ill look it up
[03:11] <kingbeowolf> wow it is taking hours to convert a video from mp4 to avi
[03:41] <kingbeowolf> OMG this is taking hours!!!!
[03:42] <kingbeowolf> only at 605MB on a 3GB file!!
[03:42] <kingbeowolf> been going for like 4 hours
[03:42] <kingbeowolf> I have an AMD 8950
[03:56] <c_14> What does your video card have to do with encoding?
[03:56] <c_14> What codec are you using?
[03:56] <c_14> What resolution is the source/destination?
[03:56] <c_14> What codec specific settings are you using?
[03:56] <kingbeowolf> the codec is xvid
[03:56] <kingbeowolf> 1080p
[03:57] <c_14> I don't know much about xvid encoding, but 1080p video is going to take a while.
[03:58] <kingbeowolf> "C:\ffmpeg\ffmpeg.exe" -y -i "C:\test\2014_08_16_16_00_09.mp4" -f avi -r:v 56 -vcodec libxvid -vtag XVID -filter:v scale=1920:1080 -aspect 4:3 -maxrate 1800k -b:v 1500k -qmin 3 -qmax 5 -bufsize 4096 -mbd 2 -bf 2 -trellis 1 -flags +aic -cmp 2 -subcmp 2 -g 300 -acodec libmp3lame -ar 48000 -b:a 128k -ac 2 "C:\test\2014_08_16_16_00_09.avi"
[04:03] <c_14> Also, XVID might be single-threaded by default.
[04:03] <c_14> not sure
[04:03] <c_14> never used it
[04:03] <c_14> Might be worth checking out.
[08:35] <K4T> hi
[08:40] <K4T> I am using ffmpeg to encode all my video files. I need to have the resulting video file to have 25 fps. I am using "-r 25" argument to force that fps.
[08:40] <K4T> Problem is that when input video have for example 23.976 fps, and I reencode it to 25 fps than I can see that output video have some little freezes during playback (from time to time, around one second interval).
[08:40] <K4T> I prepared some examples
[08:41] <K4T> original file (23.976fps): http://artnmedia.pl/damian/fps/orginal-23.976fps.mp4 and reencoded, jerky one (25fps): http://artnmedia.pl/damian/fps/reencoded-forced-25fps.mp4
[08:42] <K4T> can someone help me to find solution for that problem? I really have to reencode all my files to 25fps ;/
[08:49] <alina-emergency> is it possible to cut a piece of movie giving the [start] and the [end] and save that part as mp4 with ffmpeg system?
[09:06] <{Q}> alina-emergency: similiar to this?: http://superuser.com/questions/377343/cut-part-from-video-file-from-start-p…
[09:07] <K4T> is there any difference when I put -r argument before -i from -r after -i?
[09:09] <Mavrik> K4T, yes
[09:09] <K4T> can you explain?
[09:09] <Mavrik> before -i it means "read this file as it would have FPS of N"
[09:09] <Mavrik> and after -i it means "encode this file to fps N"
[09:09] <Mavrik> K4T, all parameters before -i set (force) parameters on the input, parameters after -i set it on output
[09:09] <K4T> output file in both scenario will have 25fps, yes?
[09:10] <K4T> ok
[09:10] <Mavrik> depends.
[09:10] <K4T> hmmm can you givde me advices how I can solve my problem from above?
[09:10] <Mavrik> you almost never want to put -r before -i
[09:10] <Mavrik> K4T, you probably need to telecine your output
[09:11] <Mavrik> because now you're just getting duplicated frames which cause freezes
[09:11] <Mavrik> there's a guide on switching fps on ffmpeg wiki
[09:11] <K4T> what about using fps filter instead of -r?
[09:12] <Mavrik> -r injects fps filter.
[09:12] <Mavrik> go read the guide.
[09:15] <K4T> I can not find that guide about switching fps on wiki :/ Blind man I am ;[ I also always trying to search docs before asking
[09:15] <K4T> If I ask that means that I did not find what I need in docs or I dont understand something
[09:15] <K4T> or I want to be sure :P
[09:17] <K4T> but thank you for hint with telecine
[09:17] <Mavrik> Someone posted the link here awhile ago, don't have time to look for it now.
[09:21] <K4T> ok
[09:24] <techtopia> hello
[09:25] <techtopia> i have been using ffmpeg to do some encodes
[09:25] <techtopia> and my encodes end up with a variable frame rate instead on constant
[09:25] <techtopia> how can i stop this happening
[09:28] <techtopia> ffmpeg.exe -y -i test.ts -sws_flags spline -sn -vf yadif=1:0,crop=1916:1080:2:0 -s 1280x720 -c:v libx264 -preset slow -crf 23 -acodec copy out.mkv
[09:28] <techtopia> this is me line
[09:32] <K4T> use -r FPS_VALUE
[09:33] <ffmpeghelpneeded> hi
[09:33] <ffmpeghelpneeded> I was asking yesterday about overlaying videos with images and have it working with the following command
[09:33] <ffmpeghelpneeded> ffmpeg -loop 1 -r 24 -i image.jpg -i video.mp4 -strict experimental -filter_complex '[0:v]scale=180:-1[watermark];[1:v]scale=360:-1[background];[background][watermark]overlay=main_w-overlay_w-0:main_h-overlay_h-0:shortest=1[video]' -map [video] -map 0:a:0 -c:v libx264 -profile:v baseline -acodec aac output2.mp4
[09:34] <ffmpeghelpneeded> I'm running this on Android using ffmpeg4android (ffmpeg4android.netcompss.com)
[09:35] <ffmpeghelpneeded> when I run this on an image file + video file, it takes about 45 seconds to process an 8 second video
[09:35] <ffmpeghelpneeded> if I change the codec to mpeg4, it takes about 20-25 seconds, which is much better, but still too slow
[09:35] <ffmpeghelpneeded> if I run two videos together, it takes about 8 seconds, which is still better, but still not ideal
[09:35] <ffmpeghelpneeded> on my computer running the same command takes about 1.5 seconds
[09:36] <ffmpeghelpneeded> and on iOS using avfoundation, I can do the same thing also in about 3 seconds.
[09:36] <ffmpeghelpneeded> any idea what I can do to improve the performance of the ffmpeg command without losing too much quality of the video?
[09:56] <K4T> that damn fps conversion, cant sleep because of it ><
[13:43] <ubitux> rudi_s: feel free to upvote http://trac.ffmpeg.org/ticket/2391
[13:45] <rudi_s> ubitux: Thanks.
[13:46] <ubitux> rudi_s: writing a vobsub demuxer was a horrible experience, so good luck with the muxer; work on this really is appreciated
[13:46] <ubitux> rudi_s: feel free to comment in the ticket, Cigaes (Nicolas) can probably help guide you
[13:46] <ubitux> he started writing a muxer but never got done with it
[13:47] <rudi_s> That doesn't sound good ..
[13:47] <ubitux> rudi_s: it's not an easy issue
[13:48] <ubitux> see http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mpeg.c;h=056db2e… for the vobsub demuxer
[13:48] <ubitux> better discuss that on #ffmpeg-devel though
[13:49] <rudi_s> ubitux: Thank you, I'll have a look.
[15:02] <Buddy2> how can I demux all audiostreams from a ts file without specifying outputfiles? Just dump everything that's audio? :)
[15:11] <anshul_mahe> I am unable to compile code on windows
[15:12] <anshul_mahe> to see error detail http://pastebin.com/ev5e74w1
[15:13] <anshul_mahe> All things were working, before I added libavutil/bprint.h and used some of those feature
[15:14] <anshul_mahe> the same code is working on linux
[15:52] <ubitux> Buddy2: not possible
[15:52] <ubitux> Buddy2: you can use ffprobe though to identify the number of streams you'll have to extract, and construct a cmd line from this
[16:17] <ionoy> what is the easiest way to stream video from one PC to another inside LAN (wifi)? I'm using this on server side: "ffmpeg -f dshow -i video="Syntek STK1150" -vcodec mpeg4 -f mpegts udp://192.168.1.100:8554" and "ffplay -i udp://192.168.1.100:8554" on desktop PC. Server is sending data, but client just stops at first line...
[16:17] <ionoy> I see packets flowing via the Wireshark
[16:18] <fajung> does ffplay display subtitle(srt or ass)?
[16:18] <ionoy> nan: 0.000 fd= 0 aq = 0KB vq= 0KB sq= 0B f=0/0 (output from client)
[16:21] <c_14> ionoy: is 192.168.1.100 the ip of the pc playing the stream?
[16:21] <ionoy> yes
[16:21] <c_14> any firewalls that might be making mischief?
[16:22] <ionoy> turned off
[16:22] <fajung> if so, how can I do to make it visible?
[16:24] <c_14> ionoy: does outputting dshow to a file work? Can you use a file as source to stream to udp?
[16:25] <ionoy> hm, I'll try
[16:48] <ionoy> c_14: Nevermind, I tried to stream with -f rtp rtp://192.168.1.100:554 and it works now. Although it only works when I encode it with libx264 and default settings. When I tried -qp 0 for lossless, received stream became really scrambled :(
[17:24] <gugusama> hi anyone tried building ffmpeg statically with x11grab ?
[17:27] <gugusama> i was trying to build it but got this error message: Xext not found
[17:31] <gugusama> CFLAGS="-I$TARGET_DIR/include" LDFLAGS="-L$TARGET_DIR/lib -lm" ./configure --prefix=${OUTPUT_DIR:-$TARGET_DIR} --extra-cflags="-I$TARGET_DIR/include -static" --extra-ldflags="-L$TARGET_DIR/lib -lm -static" --extra-version=static --disable-debug --disable-shared --enable-static --extra-cflags=--static --disable-ffplay --disable-ffserver --disable-doc --enable-gpl --enable-pthreads --enable-postproc --enable-gray --enable-runtime-cpudetect --enable-libfaac --
[17:52] <thomas_sch> I got a mkv file which chapters and subtitles.Is there a clean/easy way to convert this mkv to a dvd?I tried googling but all I got was devede and co
[18:07] <Puffton> Is it possible to stream PNG images stored in-memory in C++ to disk as a movie using ffmpeg? The PNG images will never be stored on disk themselves (could be about a million of them so it would be a lot easier to stream them straight to a movie to avoid overhead)
[18:09] <c_14> maybe look at the image2pipe demuxer
[18:13] <Puffton> ok, will look into it, thanks!
[19:11] <Puffton> Are there any benchmarks on the compression rate of ffmpeg? Like, the difference between saving a single frame as a PNG compared to saving it as part of a movie using ffmpeg?
[19:12] <c_14> Depends on the codec you're using.
[19:13] <Puffton> Was hoping to find a couple of benchmarks of the most common ones
[19:15] <sfan5> a single png is likely in almost any case bigger than a single frame of a movie (for non-lossless codecs like h264, hevc, mpeg4video, etc.)
[19:17] <Puffton> that's what I'm hoping to show, but I'm writing a report
[19:17] <sfan5> you could do the benchmarks yourself
[19:18] <Puffton> I suppose, but setting up a realistic environment for that would take me a little more time than I have right now, and the report is already too long
[19:24] <Puffton> (it's not about video compression vs storing raw PNGs at all, it just happened to be a really neat feature in the future)
[19:47] <optix2> I'm trying to create standard DV-AVI files from AVCHD mts-files. Interlaced AVCHD is TFF whereas DV has to be BFF. when using the fieldorder command the resulting file has 2x bitrate and is therefor not a valid dv file, see http://fpaste.org/127804/14087294/ and http://fpaste.org/127805/72947814/
[19:47] <optix2> omitting the fieldorder command produces a TFF DV avi with correct bitrate
[19:47] <optix2> or am I missing something?
[23:14] <CyberKitsune> Hey guys, I have a rather, particular problem. I have an mpeg file with some elementary streams in it, that look completely valid in a hex editor, but it can't be decoded by ffmpeg, or anything else for that matter!
[23:15] <CyberKitsune> I'm more than fairly certain there is no corruption, but it may be an odd kind of mpg?
[23:16] <CyberKitsune> ffmpeg in particular just thows a "Invalid data found when processing input" on the file when it tries to decode it-- I'm willing to upload it as a sample too, if somebody more skilled in video files and formats would like to take a look
[00:00] --- Sat Aug 23 2014
1
0
[00:08] <rcombs> should the null muxer be flagged AVFMT_TS_NONSTRICT?
[00:08] <rcombs> I'd say "probably"
[00:10] <jamrial> if that gets rid of the "Encoder did not produce proper pts, making some up." warning when using it, and there are no bad side effects, I'm all for it
[00:10] <rcombs> jamrial: I want it to get rid of the "Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6 >= 6" error
[00:13] <rcombs> to get rid of that warning, I think https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L478 needs ` && !(s->oformat->flags & AVFMT_NOTIMESTAMPS)`
[00:34] <rcombs> or, should AVFMT_NOTIMESTAMPS imply AVFMT_TS_NONSTRICT?
[00:40] <rcombs> https://gist.github.com/0e26f490ec13d67996fd simple enough
[02:00] <llogan> relaxed: ping
[02:44] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:331b1f7d813a: huffyuvdec: fix old (v1) rgba
[02:44] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:50a35f0d2e1a: fate: add test for old (v1) huffyuv and rgba
[02:47] <relaxed> llogan: pong
[09:37] <ubitux> kierank: so, what's the plan for ilpack?
[09:38] <ubitux> if we are able to get the same behaviour with swscale, we should probably drop the filter mentioning an example of equivalence
[09:40] <nevcairiel> i think we determined that swscale cannot do interlace chroma upsampling, while ilpack can do that
[09:41] <wm4> ilpack is a simple filter, it could be ported quickly (but not by me)
[09:41] <wm4> what about the pp ones?
[09:41] <ubitux> nevcairiel: the last entry in the thread is about {src,dst}_[vh]_chr_pos options in sws
[09:42] <ubitux> wm4: i thought uspp was useful
[09:42] <nevcairiel> isnt that for different subsampling schemes, or can that even handle interlaced chroma?
[09:43] <nevcairiel> in other news, my new opengl video players works \o/
[09:43] <ubitux> are you going to merge it in ffplay/glplay ?
[09:43] <ubitux> :-°
[09:43] <nevcairiel> you wish
[09:43] <nevcairiel> this is proprietary code
[09:43] <wm4> ubitux: libavdevice already has opengl output
[09:43] <nevcairiel> ie. i get paid!
[09:43] <ubitux> :)
[09:43] <wm4> ubitux: so you can probably make ffmpeg output to libavdevice
[09:44] <ubitux> what about a/v sync?
[09:44] <nevcairiel> i looked at that one for inspiration briefly, but its really quite basic only
[10:56] <kierank> nevcairiel: we decided it was possible with swscale
[10:59] <ubitux> kierank: can you provide an equivalent command line example?
[10:59] <kierank> nevcairiel: though thinking about it now I don't see how swscale can associate a single chroma line with two fields
[11:21] Action: rcombs presents https://gist.github.com/0e26f490ec13d67996fd again
[11:23] <nevcairiel> AVFMT_NOTIMESTAMPS should probably rather imply that
[11:23] <nevcairiel> unless all other things with AVFMT_NOTIMESTAMPS also have the flag set already
[11:24] <nevcairiel> (which they don't, apparently)
[11:24] <henry0312> wm4, kierank: I added some comments, https://gist.github.com/henry0312/b0feccedd5b9fd2e636b. If it is good, I'll submit it.
[11:25] <henry0312> (also including small changes, https://gist.github.com/henry0312/b0feccedd5b9fd2e636b/revisions)
[11:33] <wm4> henry0312: hm I'd just send it
[11:36] <kierank> Yes just send it
[11:42] <henry0312> so I need to send it only in the form of format-patch? Or some mail messages would be good?
[11:45] <wm4> using either git send-email or a format-patch as attachment should be fine
[11:45] <wm4> git send-email is probably harder to configure at first
[11:46] <henry0312> a format-patch as attachment should be fine <-- I see.
[11:55] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:c1b663bc92d3: avfilter/vf_lenscorrection: get rid of some floats
[11:55] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:2450ca0f3344: avfilter/vf_lenscorrection: get rid of all floats per frame
[11:55] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:32cb6c1fe28f: avfilter/vf_lenscorrection: get rid of floats in init code
[12:34] <cone-895> ffmpeg.git 03Clément BSsch 07master:980a5b01fd07: avutil/motion_vector.h: fix coordinate types
[12:36] <cone-895> ffmpeg.git 03Clément BSsch 07master:f5ddce0753c5: doc/APIChanges: fill 2 hashes from my recent API additions
[13:27] <kierank> ubitux: afaik it's not possible to do interlaced upsampling from the cli
[13:27] <kierank> you'd have to hack the scale filter to use the same chroma line for each luma line
[13:28] <ubitux> do you think it would be a better solution than porting the filter?
[13:36] <Compn> rcombs : i'll post it to the list for you :)
[13:38] <henry0312> Anyone uploads https://dl.dropboxusercontent.com/u/25391619/aribu_sub_sample.ts to somewhere and post the thread, https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/161619.html, please.
[13:38] <henry0312> Probably, Japanese law prohibits me to do that.
[13:39] <Compn> henry0312 : ok , i can do it :)
[13:39] <henry0312> Compn: thanks!
[13:39] <Compn> henry0312 : can we put this sample on http://samples.ffmpeg.org ? or should we keep it a private sample ?
[13:40] <Compn> that only devels can access
[13:40] <henry0312> Compn: I think it's better to keep it private..
[13:40] <Compn> ok, private it is.
[13:43] <Compn> henry0312 : no arib sub profile b support? :P
[13:43] <Compn> ehe
[13:43] <Compn> ( i dont know if it even exists)
[13:44] <henry0312> Compn: yeah, I think aribb24 doesn't support profile b. https://github.com/nkoriyama/aribb24
[13:45] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:b09ea25fec61: avfilter/vf_lenscorrection: fix memleak
[13:46] <Compn> ah
[13:46] <Compn> henry0312 : ok, sample uploaded, thanks
[13:46] <henry0312> Compn: thx!
[14:10] <Compn> argh, why is atilla flaming so hard on the list
[14:10] <Compn> crazyness
[14:16] <kurosu> henry0312, if you want a sample to remain private, don't paste its link in a channel that is logged ;)
[14:16] <J_Darnley> Is that thread still going on?
[14:17] <Compn> J_Darnley : yes
[14:17] <Compn> and it is super flame
[14:18] <Compn> i ask all ffmpeg devels to not engage with the flames on deb-devel.
[14:18] <Compn> feel free to flame on our lists of course :P
[14:18] <nevcairiel> they stopped CCing ffmpeg-devel, i dont get the shit anymore
[14:19] <henry0312> hmm....
[14:19] <ubitux> yes, they mail privately now ;)
[14:19] <Compn> henry0312 : anyways, you should be ok copyright wise for sharing a small clip. of course i know japanese copyright can be tricky now...
[14:27] <henry0312> Compn: sound more familiar with japanese copyright than I xD
[14:27] <cone-895> ffmpeg.git 03Christophe Gisquet 07master:4728cdd88033: imc: reject files with unfathomable sampling rates
[14:38] <michaelni> ubitux, is "[PATCH] Disable chunked output for Icecast" ok ? i think you know/worked on icecast ?
[14:38] <ubitux> just as a user; i don't know icecast nor its relationship with chunked post
[14:39] <ubitux> i didn't have such issue, so dunno
[14:45] <J_Darnley> > unfathomable
[14:45] <J_Darnley> brilliant
[14:47] <nevcairiel> discussions always get much more interesting when people bring out the big words to sound more believable
[14:56] <kurosu> next on my list: put furlong per fortnight in a commit message
[14:58] <nevcairiel> hm, didnt the x264asm automatically insert mova's when using 3 argument forms on non-avx?
[14:58] <ubitux> it should yes
[14:59] <nevcairiel> i'm mostly wondering about blocks like this: http://pastebin.com/paHyAGQQ
[14:59] <nevcairiel> but maybe i'm missing something
[14:59] <kurosu> nevcairiel, hopefully you are just kidding and not blaming me for tricking or being... highfalutin ?
[15:00] <ubitux> nevcairiel: maybe for forcing pairing? dunno
[15:00] <ubitux> not sure if that's actually relevant
[15:01] Action: nevcairiel will just ask the author of said patch
[15:02] <kurosu> yeah, unless you have a cpu with poor ooe (atom?), I don't see the benefit
[17:23] <cone-895> ffmpeg.git 03Stefano Sabatini 07master:aade9884e95c: lavfi/apad: fix logic when whole_len or pad_len options are specified
[17:23] <cone-895> ffmpeg.git 03Stefano Sabatini 07master:7e4a4bda0e5a: doc/filters/apad: extend documentation
[17:33] <michaelni> kurosu, ive a better fix for #3866
[17:35] <michaelni> theres a integer overflow
[17:42] <kurosu> in the patch (I thought all computations added were on int64_t), or as the source of the error ?
[17:43] <kurosu> michaelni, anyway, please post
[17:43] <kurosu> I think the patch is somewhat incorrect anyway because it makes an error of something that was swallowed on purpose previously
[17:44] <michaelni> kurosu, posted, ok to push ?
[17:50] <kurosu> michaelni, ok
[17:50] <kurosu> I really didn't notice that one
[17:51] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:a9f3bb14ba8b: avformat/mov: use 64bit for size in mov_skip_multiple_stsd()
[17:51] <michaelni> kurosu, pushed, thx
[18:06] <cone-895> ffmpeg.git 03Christophe Gisquet 07master:4a5cc34b46a8: wavpackenc: assert on too small buffer
[19:26] <alexfu> i'm attempting to display live streaming video directly from device to device over a network and i'm noticing a ~20sec delay. I read ffmpeg streaming guide and it pointed out that one way to reduce latency is by specifying more frequent I frames. where does this configuration go in terms of the ffmpeg C api?
[19:27] <kierank> that doesn't affect latency
[19:27] <kierank> i-frames affect seek time
[19:27] <JEEB> and how long it takes for a client to get a proper picture
[19:28] <JEEB> when joining at a random point of time
[19:28] <JEEB> but yes, latency-wise it really doesn't affect :P
[19:28] <alexfu> i notice about a 4 sec initial startup
[19:28] <JEEB> you should make sure 1) ffmpeg doesn't buffer much data and 2) your encoder doesn't buffer much data if you want to minimize latency
[19:29] <JEEB> for x264 -tune zerolatency, for ffmpeg I just don't know :P
[19:32] <alexfu> JEEB: what's a reasonable size for a buffer in this scenario?
[19:32] <nevcairiel> 20 seconds is way more than your usual encoder latency. Sounds more like something buffers too much when streaming
[19:33] <JEEB> alexfu, I meant pictures getting buffered :P
[19:33] <JEEB> and/or input data
[19:39] <alexfu> oh. if i'm correct, i think an entire picture is being buffered at a time and then being displayed.
[20:01] <alexfu> yeah, i have no idea where to start looking.
[20:35] <alexfu> anything in this http://pastebin.com/HRV0A7KS that might appear to be completely incorrect for live streaming?
[20:59] <rcombs> nevcairiel: hmm, I pondered that as well; think we can safely make that change? (i.e. have AVFMT_NOTIMESTAMPS be a mask containing AVFMT_TS_NONSTRICT)
[21:01] <nevcairiel> I would just change the code that checks the flag to check for either
[21:02] <nevcairiel> Can't be more then 1-2 spots
[21:11] <wm4> __gb__: so any news on the vaapi locking issue?
[21:13] <cone-895> ffmpeg.git 03James Almer 07master:54ca4dd43bdc: x86/hevc_res_add: refactor ff_hevc_transform_add{16,32}_8
[21:30] <cone-895> ffmpeg.git 03Diego Biurrun 07master:11cd727fbd60: vsrc_movie: Adjust a silly typo from b977b287f61fea48ecd6251d54a26334213b7ec6
[21:30] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:24e81a0a8d86: Merge commit '11cd727fbd603197cb1e49654fce3352d56f8fd8'
[21:38] <cone-895> ffmpeg.git 03Diego Biurrun 07master:7cb66ebc0be4: error_resilience: Drop asserts from guess_mv()
[21:38] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:f6ff1cb1bae5: Merge commit '7cb66ebc0be48489785f7166c9d15eac594b0763'
[21:44] <cone-895> ffmpeg.git 03Diego Biurrun 07master:8fc6a70c2167: mpeg12enc: Add missing #include for PICT_FRAME
[21:45] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:4f49c39a2fec: Merge commit '8fc6a70c2167b645b7a37d0cbc0e276e7b787cc9'
[21:56] <cone-895> ffmpeg.git 03Diego Biurrun 07master:593aaee953f8: setpts: Add missing inttypes.h #include for PRId64
[21:56] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:2bfd4ff16ddd: Merge commit '593aaee953f8b07c141ff115e67bae85ef0350c7'
[22:02] <cone-895> ffmpeg.git 03Nidhi Makhijani 07master:13c90bc9a359: adts: Return more meaningful error codes
[22:02] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:fca76dc61ed6: Merge commit '13c90bc9a359e969cc2b7f7e8199b02a0e4c6ec9'
[22:14] <cone-895> ffmpeg.git 03Christophe Gisquet 07master:0625a3806628: hevc_ps: check overflow and test alternate syntax
[22:51] <Compn> rcombs : what if people use nullenc and want to know about timestamp errors ?
[22:54] <rcombs> Compn: do they?
[23:12] <cone-895> ffmpeg.git 03Christophe Gisquet 07master:b3d6543caf3b: dpxenc: fix padding in encode_gbrp12
[23:15] <kurosu> michaelni, the stream found in #3872 seems something we will hardly ever encounter again
[23:16] <kurosu> no real point in me mentioning it, just maybe we should not worry if we have to change that code again
[23:16] <Compn> rcombs : no idea , its possible :P
[23:16] <Compn> rcombs : apparently our fate tests use timestamp info
[23:16] <Compn> in nullenc
[23:17] <Compn> there are replies to your patch on ffmpeg-devel
[23:17] <Compn> if you care to read them
[23:18] Action: rcombs looks
[23:19] <michaelni> kurosu, iam not sure its so rare, there are h264 streams with strange truncated or non escaped SPS too
[23:20] <michaelni> but the hevc case isnt just "not escaped"
[23:21] <rcombs> Compn: hmm, I tend to agree with h.leppkes (and nevcairiel) that it'd make more sense to adjust the code that prints the error. As for people who want that error, maybe it could be an option?
[23:21] <ubitux> h.leppkes and nevcairiel rarely disagree
[23:22] <ubitux> they're like brothers
[23:22] <ubitux> twins, even
[23:23] Action: rcombs WHOISs
[23:23] <rcombs> oh, well then
[23:23] <gnafu> ubitux: iseewhatyoudidthere.jpg
[23:28] <kurosu> michaelni, I suspect this was from an encoder whose sps writing code wasn't updated at the time
[23:28] <kurosu> the mkvmerge code seems to have it correct since day 1 (which seems to be early 2013)
[00:00] --- Fri Aug 22 2014
1
0
[00:00] <RaZoR37> okay
[01:33] <vlatkozelka> Im trying to save a udp stream containing TV channels onto segments ... the recording is fine but , the timestamp is being reset so start is 00:00:00 , everything else is good . I tried -copyts but didnt work and made things worse , now it records like 30 1 second long ts files then the rest the time i need but still timestamps are reset .
[01:33] <vlatkozelka> http://pastebin.com/pRWBaSad
[01:33] <vlatkozelka> can anyone help me with this ?
[06:16] <profit___> so i'm having a bad time trying to stream audio + a png to an RTMP server.
[06:16] <profit___> it stops immediately.
[06:17] <profit___> http://hastebin.com/bogecikiju.mel is what i try to run, and it immediately stops (hence the output)
[06:18] <profit___> i've tried including -loop 1 before the PNG file to no avail either
[08:14] <sekon> Hello,
[08:15] <sekon> I am trying to compile ffmpeg with libvo_aacenc
[08:18] <Zhenya> Hello
[08:18] <Zhenya> Who knows how to set a subtitle stream as default & forced?
[08:19] <ParkerR> Zhenya, forced as in forced on or forced as in hard coded?
[08:20] <Zhenya> ParkerR: By using mediainfo. I see two flags per stream. default:no force:no. So I want to open the subtitle by default
[08:21] <ParkerR> Maybe a bug https://trac.ffmpeg.org/ticket/2402
[08:21] <Zhenya> ParkerR: I have tried -metadata:s:0 default=1 ,but then I got two default flags... default:no, DEFAULT:1
[08:22] <ParkerR> "What is missing afaict is a possibility for the user to mark streams as default streams, an alternative is to always set the first stream as default in the Matroska muxer, I am not completely convinced that this is the best solution, consider sending a patch if that is what you want."
[08:24] <Zhenya> ParkerR: I am not sure that I have the ability to do the fix....
[08:24] <ParkerR> Not saying you do. I was just copy and pasting the first comment :P
[08:24] <Zhenya> ParkerR: Do you know how to make the subtitle as the first stream so it will be default on?
[08:25] <ParkerR> Not sure
[08:26] <Zhenya> ParkerR: Opened 17 months ago
[08:32] <klaxa> Zhenya: afaik ffmpeg does not support that feature yet, use mkvtoolnix for now
[08:33] <Zhenya> klaxa: Thanks
[09:38] <Buddy2> Hi, I would like to demux the AC3 stream of a ts file with 2 audiostreams, I tried the map function but sometimes the AC3 stream is 0:1 and sometimes the AC3 stream is 0:2 How can I make sure I always only demux the AC3 stream of the file?
[09:38] <Buddy2> ffmpeg -i input.ts -acodec copy -map 0:2 -vn audio.ac3
[09:39] <Buddy2> mediainfo always says that the AC3 stream is secondary audio
[09:39] <Buddy2> so I don't understand why ffmpeg sees it as primary sometimes
[09:39] <Buddy2> Stream #0:1[0x2c9](eng): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, stereo, fltp, 192 kb/s
[09:39] <Buddy2> Stream #0:2[0x265](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 192 kb/s
[10:37] <alina-emergency> hey all for example if i want to cut a fragment like 34:20 - 36:20 and export that part as mp4 is that possible to do?
[11:12] <myubuntu> Can ffmpeg do audio mixing?
[11:16] <ubitux> yes
[11:21] <myubuntu> But I can't find any code.
[11:26] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#amerge
[11:26] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#amix
[11:28] <myubuntu> thanks, I 'll check
[12:51] <bigzed__> Hi, does anyone of you know if FFmpeg supports DnxHD in an MXF container created by Avid?
[13:06] <relaxed> bigzed__: I believe so
[13:08] <bigzed__> relaxed, I have exactly such a file here, but this is what FFmpeg says about it without encoding it. http://pastebin.com/vHz1cT2F
[13:08] <bigzed__> Do I have to specify special options for it?
[13:10] <relaxed> do you have any others files to test?
[13:12] <relaxed> https://code.google.com/p/ffmbc/ might have better support for them.
[13:17] <bigzed__> checked with FFmbc as well, but it stops with this http://pastebin.com/Ce1nQa7N
[13:17] <bigzed__> do you know if it is possible to specify the pixel format by hand?
[14:07] <needffmpeghelp> hi
[14:07] <needffmpeghelp> I am working on adding an overlay to either a video or an image
[14:07] <needffmpeghelp> if I want to overlay an image or a video on top of another video, that seems to work with:
[14:08] <needffmpeghelp> ffmpeg -y -i image.jpg -strict experimental -vf "movie=video2.mp4, scale=90:-1 [watermark]; [in][watermark] overlay=main_w-overlay_w-36:main_h-overlay_h-48 [out]" -c:v libx264 -profile:v baseline -acodec aac videoOutput.mp4
[14:08] <needffmpeghelp> sorry, that doens't work
[14:09] <needffmpeghelp> ffmpeg -y -i video.mp4 -strict experimental -vf "movie=video2.mp4, scale=90:-1 [watermark]; [in][watermark] overlay=main_w-overlay_w-36:main_h-overlay_h-48 [out]" -c:v libx264 -profile:v baseline -acodec aac videoOutput.mp4 works
[14:09] <needffmpeghelp> that works
[14:09] <needffmpeghelp> but if I put the image as the first input, then I end up with a 1 frame video
[14:09] <needffmpeghelp> and if I do -loop 1 at the beginning, then the video never stops
[14:10] <relaxed> bigzed: yes, ffmpeg -pix_fmt $format -i input
[14:10] <needffmpeghelp> basically what I want is for the video to be as long as the longest video (either the video or the overlay), and if it's an image as the background then I want the image to display for the full length of the other input
[14:12] <relaxed> needffmpeghelp: it's recommended to use -filter_complex now for overlays and watermarks
[14:19] <needffmpeghelp> ok, I'll try read up on it a bit and come back if I still need help
[14:33] <Buddy2> how can I demux all audiostreams from a ts file without specifying outputfiles? Just dump everything that's audio? :)
[14:39] <slowguy> i need to print all the keyframe timestamp in a file..i am using ffprobe but its very slow
[14:40] <slowguy> is it possible to make ffmpeg dump this info at the time of encoding itself?
[15:16] <davis> hello
[15:17] <davis> im trying to follow along with the ffmpeg basics book. I'm also looking at the online ffmpeg docs.
[15:18] <davis> early in the book and on this page here
[15:18] <davis> https://www.ffmpeg.org/ffmpeg.html#Synopsis
[15:18] <davis> is a description of how to overlay two videos.
[15:18] <davis> the approach is similar, it looks this
[15:19] <davis> ffmpeg -i foo.mkv -i goo.mkv -filter_complex 'overlay' boo.mkv
[15:19] <davis> however, when I do this, I get an error about "Unrecognized option" filter_complex
[15:20] <davis> ive tried using the longer command syntax describe but it still fails.
[15:20] <ubitux> but you're probably just outdated, like with a several years old ffmpeg
[15:21] <ubitux> you probably have a ffmpeg that is at least 3 years old
[15:21] <davis> hmm. I was using the one built in to ubuntu distro. Should I use a custom site or build from source?
[15:21] <ubitux> right, so you're not even using ffmpeg but a fork, so yeah no surprise
[15:21] <ubitux> you'd better build from the source yes
[15:22] <davis> ok, i'll try to pull frm git and see if I can get it to build on this distro
[17:43] <relaxed> davis: or http://johnvansickle.com/ffmpeg/
[19:45] <lenarhoyt> hi, I'm trying to convert Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default) to mp3
[19:46] <lenarhoyt> however the file turns out to be twice as long and some parts repeat
[19:51] <lenarhoyt> http://pastie.org/private/etle8g5qjbpyosoelqrya
[19:52] <relaxed> llogan: what did you need?
[19:52] <lenarhoyt> A.m4a is 08:00:33.35, while B.mp3 is about 18:18:24.00 long
[19:54] <lenarhoyt> 2,25 is an odd factor :/
[19:55] <lenarhoyt> hm, ffmpeg recognizes the length correctly
[19:55] <lenarhoyt> its only apples mp3 decoder
[19:56] <lenarhoyt> http://i.imgur.com/sVUs6ZQ.png
[19:57] <lenarhoyt> http://pastie.org/private/ebgjyyvo9ydrcafeidscya
[20:02] <llogan> relaxed: burek seems to have vanished, and his builds have vanished. i was thinking of providing 32 builds. got a script i can base if off? </lazy>
[20:02] <llogan> i mean his builds have halted
[20:04] <llogan> lenarhoyt: might be bug https://trac.ffmpeg.org/ticket/2697
[20:04] <relaxed> I can add 32bit builds this weekend
[20:04] <llogan> ok, that works too
[20:04] <llogan> thanks
[20:04] <llogan> ping me and i'll update the download page
[20:05] <relaxed> will do
[20:12] <brontosaurusrex> is something like "ffprobe -show_frames -of compact=p=0 -f lavfi "movie=MOVIEFILENAME,select=gt(scene\,.4)" > MOVIEFILENAME.csv" doable with ffmpeg as well, or must I use ffprobe?
[20:13] <anshul_mahe> no not possible with ffmpeg, you can refer man ffmpeg
[20:14] <anshul_mahe> -show_frames is only possible with ffmpeg
[20:14] <anshul_mahe> is libavfilter thread safe.
[20:15] <anshul_mahe> ?
[20:18] <anshul_mahe> When i call avfilter_graph_free while using all input filter, it gives me seg fault
[20:20] <rudi_s> mencoder supported -vobsoubout to dump the subtiles as .idx and .sub files. Is this still possible with ffmpeg?
[20:20] <rudi_s> I tried to convert the .vob to .mkv, but it seems the idx-"part" is not correctly transferred, as mkvextract doesn't let me extract the .idx/.sub from the resulting mkv file.
[20:20] <rudi_s> (codecprivate seems to be missing.)
[20:47] <lameiro> hi. I am running the following command line ( http://pastebin.com/nWk2swUd ) with latest zeranoe windows 32-static build and i get videos shorter than I expect - 60s expected, 59.1s generated according to mediainfo. I see in the ffmpeg verbose log 591 frames encoded (which matches the length/framerate). My concat.txt file has 60 jpegs, all exact same width and height. I searched the forums but couldn't really find anything similar. Can anybody clar
[20:47] <lameiro> ify?
[21:42] <c_14> lameiro: have you tried the image2 demuxer?
[21:42] <lameiro> c_14, no, i will read up and try it, thanks for the pointer
[22:06] <lameiro> c_14, got exactly same result ( http://pastebin.com/jm2GeLNB ) - thanks anyway
[22:08] <c_14> Are the first/last frames displaying correctly when you play the output?
[22:26] <lameiro> c_14, from visual inspection the first frame is playing too fast (not for 1sec) and maybe the last as well, but for the latter i can't be sure just visually. (is there any way to see interframe timing? i am using latest VLC as player)
[22:28] <lameiro> c_14, all images are there for sure though
[22:30] <c_14> If you can get some sort of OSD up, you can check the timing against that.
[22:31] <c_14> Heck, you could timestamp with ffmpeg.
[22:31] <c_14> I just asked because I've had people here with issues where the first/last frame didn't display/only for a split-second.
[22:35] <lameiro> c_14, found in vlc how to do frame stepping, indeed first image is only displayed for 1 frame, while others stay for 10 frames as expected.
[22:35] <c_14> Can you switch from using -r 1 to -framerate 1 ?
[22:43] <c_14> Ok, so I went back through my logs. If your problem is the same as the one in my logs, you can fix it by outputting to matroska instead of mp4, or by using -vf fps=10 instead of -r 10 (though in that case the last frame might be cut short)
[22:44] <c_14> Though I'd try that with the -framerate 1 first just in case.
[22:51] <lameiro> with -framerate 1 (no change at output -r, should I?): http://pastebin.com/ukX6uSv1
[22:51] <lameiro> same result, first frame too short
[22:53] <c_14> Ok, that one was a longshot. But try outputting to mkv/using the fps filter.
[22:55] <lameiro> i will try those 2 things, thanks very much c_14
[23:41] <rjp421> do i need to specify a/v codecs again before appending another output using -f flv <rtmp_uri>?
[23:41] <c_14> yes, unless you use the tee muxer
[00:00] <vlatkozelka> Im trying to save a udp stream containing TV channels onto segments ... the recording is fine but , the timestamp is being reset so start is 00:00:00 , everything else is good . I tried -copyts but didnt work and made things worse , now it records like 30 1 second long ts files then the rest the time i need but still timestamps are reset .
[00:00] --- Fri Aug 22 2014
1
0