Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- August
- 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
September 2013
- 1 participants
- 58 discussions
[00:00] <BBB> if its stack it should be LOCAL
[00:00] <BBB> and why does vp8 go there?
[00:01] <durandal_1707> well i need to double check (enabling symbols, etc...)
[00:05] <durandal_1707> i just looked at x86/h264_qpel and it use DECLARE_ALIGNED for stack
[00:11] <durandal_1707> actually crash is in ff_vp8_v_loop_filter16y_inner_sse2
[00:13] <durandal_1707> which doesn't make sense as that is covered by yasm
[00:20] <BBB> -eneedmoreinfo
[00:57] <cone-52> ffmpeg.git 03Paul B Mahol 07master:79b70e47a463: w64dec: fix skipping of unknown guids
[00:58] <saste> did someone compare deshake and libvidstab?
[00:59] <durandal_1707> deshake is awfull, libvidstab is little better
[01:00] <durandal_1707> (from other people experience - not me)
[01:01] <saste> durandal_1707, thanks
[01:02] <saste> durandal_1707, is phase supposed to fix the same problem as fieldorder (but in a different way)?
[01:02] <durandal_1707> i think you could search & read older irc logs...
[01:03] <saste> what about the old transcode stabilizer?
[01:03] <saste> i'm asking because i had a discussion with a guy about that
[01:03] <durandal_1707> not at all
[01:03] <durandal_1707> what guy?
[01:03] <saste> i was convinced that deshake used the same algorithm
[01:04] <saste> (as the transcode stabilizer)
[01:05] <saste> the guy - a vlc dev
[01:05] <durandal_1707> fieldorder filter changes top to bottom or vice versa (for same frame)
[01:06] <saste> durandal_1707, yes
[01:06] <durandal_1707> what algorithm?
[01:08] <saste> durandal_1707, same algorithm == equivalent implementation/port
[01:09] <durandal_1707> but what/where in codebase (i'm not on simple english class)
[01:09] <durandal_1707> you mean deshake use same code as phase?
[01:11] <saste> durandal_1707, what a confusion, no
[01:11] <saste> i was asking if there is any relation between the transcode project stabilizer and deshake
[01:12] <saste> fieldorder/phase is a separate topic
[01:13] <durandal_1707> saste: i didn't looked closely at deshake/stabilizer/whatever
[01:13] <GoaLitiuM> btw, any plans on supporting intel quick sync encoding?
[01:15] <durandal_1707> i don't think it is on TODO list
[01:15] <durandal_1707> but we do not have TODO list at all
[01:19] <Compn> GoaLitiuM : someone was talking about that on the list
[01:19] <GoaLitiuM> recently?
[01:19] <Compn> no
[01:19] <Compn> probably when it was announced
[01:19] <Compn> at least that , or my memory is making up timestamps again
[01:21] <durandal_1707> if it is on bug tracker, at least someone could see it have been at least requested
[01:22] <durandal_1707> ah here it is: http://trac.ffmpeg.org/ticket/2591
[01:24] <durandal_1707> and there are some patches floating on fork side
[03:06] <cone-52> ffmpeg.git 03Paul B Mahol 07master:3e36dc8626f4: w64dec: fix end position of summarylist guid
[03:29] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:cc84f3040261: avutil/fifo: assert that theres enough data in the fifo on drain calls.
[05:16] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:92b7e7b31817: avfilter/vf_yadif: reallocate frames if strides differ
[11:08] <ubitux> ffmpeg -f lavfi -i testsrc -t 5 -pix_fmt yuva420p -c:v libopenjpeg -y test.avi
[11:08] <ubitux> funny output ^
[11:26] <ubitux> anyone has interesting samples with alpha layer?
[11:27] <Compn> i only know of that one lara shadow one
[11:28] <Compn> vp6a
[11:44] <ubitux> Compn: can you share? i'm interested
[11:53] <ubitux> btw, don't we have a public function for:
[11:53] <ubitux> int has_alpha = desc ? desc->nb_components % 2 == 0 : 0;
[11:53] <ubitux> ?
[13:49] <Compn> ubitux : larashadow_dl.flv
[13:49] <Compn> ubitux http://samples.ffmpeg.org/FLV/flash_with_alpha/
[13:50] <ubitux> Compn: thanks
[13:50] <Compn> i think someone made a command line to get it to display, using ffmpeg filter
[13:50] <Compn> but i forgot the command line
[13:50] <Compn> it should be in irc log
[13:50] <Compn> http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2013-June/001425.html
[13:51] <Compn> you were there even :)
[13:51] <ubitux> it's fine
[13:51] <ubitux> im using mpv -vo opengl:alpha
[13:51] <Compn> what kind of samples did you want ?
[13:51] <ubitux> (+xcompmgr)
[13:51] <ubitux> that kind of sample :)
[13:51] <ubitux> that one is fine thx
[13:51] <Compn> oh ok
[13:52] <Compn> ah
[13:52] <cone-105> ffmpeg.git 03Anton Khirnov 07master:8aba7968dd60: vcr1: add sanity checks
[13:52] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:8ba683e629bd: Merge commit '8aba7968dd604aae91ee42cbce0be3dad7dceb30'
[13:52] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:164b67ca281f: avcodec/vcr1: replace redundant checks from libav (8aba7968dd604aae91ee42cbce0be3dad7dceb30) by asserts
[13:52] <Compn> hows mpv going ? some people asked me about mplayer forks :)
[13:52] <ubitux> it's going pretty well so far afaict
[13:54] <durandal_1707> unlike mplayer it supports lavfi
[13:55] <ubitux> and it's usable to watch animes too
[13:56] <Compn> oooo, lavfi support
[13:56] <Compn> well it was suggested to add it to mplayer, but the api was changing
[14:13] <cone-105> ffmpeg.git 03Anton Khirnov 07master:5f7aecde02a9: pictordec: break out of both decoding loops when y drops below 0
[14:13] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:efb21b0a8fbc: Merge commit '5f7aecde02a95451e514c809f2794c1deba80695'
[14:16] <cone-105> ffmpeg.git 03Anton Khirnov 07master:fe9bb61f9a16: pictordec: pass correct context to avpriv_request_sample
[14:16] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:1eb151c501ec: Merge commit 'fe9bb61f9a16be19ad91875632c39e44b7a99a8a'
[14:18] <cone-105> ffmpeg.git 03Compn 07master:8d14596bc241: riff: add 0x64 to g726 works on g726-test1.wav
[14:29] <cone-105> ffmpeg.git 03Anton Khirnov 07master:fab694dd3931: lavf: move a variable declaration to the block where it's used
[14:29] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:b0ba2bf8c66f: Merge commit 'fab694dd3931b1c0bc3c598c3f88b1902c14a303'
[14:38] <durandal_1707> what does MP_IMGFIELD_ORDERED means?
[14:47] <Daemon404> google says if MP_IMGFIELD_ORDERED is set, then teh field order is known
[14:47] <Daemon404> and you can check for TFF or BFF
[14:47] <Daemon404> i dont know why you would do it this way
[14:47] <Daemon404> but it's shitty mplayer code... unsurprising
[14:48] <nevcairiel> i would like such a flag in ffmpeg, tbh. You never know if it just defaults to bff or if the bitstream actually said so
[14:48] <Daemon404> how would that make a difference?
[14:48] <Daemon404> if you dont know, you have to guess anywa
[14:48] <Daemon404> y
[14:49] <nevcairiel> sure, but ffmpeg doesnt guess, it just defaults to tff=0
[14:49] <Daemon404> well ideally you would have two flags: one for bff, one for tff
[14:49] <Daemon404> if neither is set, then you dont know
[14:49] <Daemon404> a third flag is redundant
[14:49] <durandal_1707> and what if both are set?
[14:50] <nevcairiel> implementation is irrelevant, i just would like to identify the "unknown" case
[14:50] <Daemon404> indeed
[14:50] <Daemon404> durandal_1707, http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-March/024931.html
[14:50] <Daemon404> this should contain all the info you need
[14:50] <cone-105> ffmpeg.git 03Anton Khirnov 07master:df33a58e5311: lavf: avoid integer overflow when estimating bitrate
[14:50] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:d07d54fd5603: Merge commit 'df33a58e5311ee9a64a573889b883a80e981af7b'
[14:50] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:a5d67bc796e1: avformat/utils: Fix bitrate overflow check
[14:51] <Daemon404> yay, the fix wasnt in the merge commit!
[14:51] <Daemon404> and it has an explaation
[14:51] Action: Daemon404 cheers
[14:52] <nevcairiel> the original check did indeed look a bit funky
[14:58] <cone-105> ffmpeg.git 03Anton Khirnov 07master:a7c1689dedd1: 4xm: check that bits per sample is strictly positive
[14:58] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:bdb4ed963f7e: Merge commit 'a7c1689dedd11689edb30088d467ac03f9b8d1cf'
[15:05] <cone-105> ffmpeg.git 03Anton Khirnov 07master:488b2984fece: ape demuxer: check for EOF in potentially long loops
[15:05] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:50fd98b7ac4c: Merge commit '488b2984fece7ad0c2596826fee18e74aa904667'
[15:07] <durandal_1707> michaelni: please, please, please stop adding your changes into merges
[15:08] <nevcairiel> didnt we just discuss how he didn't?
[15:09] <durandal_1707> look at last one
[15:10] <nevcairiel> i see no extra changes
[15:12] <Daemon404> i do
[15:12] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=50fd98b7ac4c410f4413d3…
[15:12] <nevcairiel> click on the diff below the 1 for the actual changes in that merge
[15:13] <Daemon404> yes but the ones shown tehre are the extra ones
[15:13] <Daemon404> that are in the merge itself
[15:13] <nevcairiel> nope
[15:13] <Daemon404> they do not match the merge
[15:13] <durandal_1707> stupid git
[15:13] <Daemon404> nevcairiel, then what ARE they
[15:13] <cone-105> ffmpeg.git 03Diego Biurrun 07master:7df9e693a34c: cosmetics: Fix ATRAC codec name spelling
[15:13] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:4cfe3b740543: Merge commit '7df9e693a34c84c698da60426c78140c950f95ed'
[15:13] <nevcairiel> no idea how it decides what to show there
[15:13] <Daemon404> its changes made in the merge >.>
[15:14] <Daemon404> i dont know how you can see it any other way
[15:15] <Daemon404> hmmm or it might be existing things?
[15:15] <Daemon404> this is why i hate git's way of merging
[15:15] <Daemon404> its impossible to follow
[15:16] <nevcairiel> quite simply because the warning about the missing seektable was in there before the merge
[15:16] <Daemon404> yes i just realized that
[15:16] <Daemon404> but my point stands about git merges being a crapshoot
[15:16] <nevcairiel> click the diff below the 1
[15:16] <nevcairiel> it shows the actual diff against ffmpegs parent
[15:17] <nevcairiel> while 2 shows the diff against libavs parent
[15:17] <Daemon404> diff1 is the diff against libav
[15:17] <Daemon404> iirc
[15:17] <Daemon404> diff2 is ffmpeg's diff against libav
[15:17] <Daemon404> diff1 is not against ffmpeg.
[15:17] <nevcairiel> diff 1 is the diff of the current version against the ffmpeg parent, diff 2 is the diff of the current version against libavs parent
[15:17] <nevcairiel> the second contains all ffmpeg changes, of course
[15:18] <nevcairiel> so its a "diff against libav" if you want
[15:19] <nevcairiel> find a commit with clear signs of in-merge changes and confirm diff 1 behaviour, if you insist :)
[15:19] <Daemon404> hmm yorue right
[15:19] <nevcairiel> now what the web thing shows in the merge overview page completely escapes me
[15:19] <Daemon404> "clear signs of in-merge" is an oxymoron btw
[15:19] <nevcairiel> you know what i mean :P
[15:20] <Daemon404> nevcairiel, my main issue is that merges make finding things in git history very hard
[15:20] <Daemon404> especially bisects
[15:20] <nevcairiel> yeah bisecting sucks
[15:20] <Daemon404> its weird that it was designed i na way which breaks git's other features
[15:20] <nevcairiel> browsing a single files history is ok'ish
[15:20] <Daemon404> but it was probably only meant for the subset that the kernel uses it for
[15:21] <nevcairiel> yeah two completely different branches co-existing is a odd use case
[15:21] <Daemon404> not really
[15:21] <Daemon404> when you consider teh pre-git definition of fork
[15:21] <Daemon404> git changed that word to have different connotations
[15:22] <Daemon404> as a side note: sometimes i have to fall back to good old patch/diff, because git hasb een too throroughly derped up
[15:22] <Daemon404> manual patches ftw
[15:23] <nevcairiel> never had that happen
[15:23] <nevcairiel> usually gits 3 way merge managed to fix it, unless it was really not automatically fixable (code modified on both ends)
[15:23] <pippin> I prefer rebase based workflows, leading to a linear commit history
[15:24] <Daemon404> everybody does
[15:24] <Daemon404> thats not suitable for this use case though
[15:24] <cone-105> ffmpeg.git 03Martin Storsjö 07master:0fbda03e5cfc: movenc: Don't flush after each written packet
[15:24] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:40bb950385a4: Merge remote-tracking branch 'qatar/master'
[15:33] <ubitux> can avcodec_decode_video2() return EAGAIN?
[15:37] <durandal_1707> aac_latm does
[15:38] <av500> aac does video now?
[15:38] <durandal_1707> no... but it returns
[15:38] <durandal_1707> that is only EAGAIN in lavc
[15:39] <durandal_1707> and i see no reason for it...
[15:41] <ubitux> mmh interesting
[15:41] <ubitux> well if that's for audio i don't care in my case but that's good to know
[15:42] <durandal_1707> when would you use it?
[15:44] <ubitux> i'm just wondering if i can error out in case of ret < 0
[15:44] <ubitux> or if i need to add a EAGAIN check
[15:44] <ubitux> (in addition)
[15:45] <nevcairiel> i just error out on < 0
[15:45] <nevcairiel> never found something where this doesnt work
[15:45] <ubitux> yeah actually i just realize there is the got_frame thing
[15:45] <ubitux> so eagain should not happen
[15:47] <Daemon404> yes
[15:49] <ubitux> what about the read frame?
[15:49] <nevcairiel> there i handle it
[15:49] <nevcairiel> not sure if it really happens
[15:49] <ubitux> i remember a lot of weird cases
[15:49] <nevcairiel> i think it can, depending on the underlying protocol
[15:49] <ubitux> like packets of size 0
[15:49] <ubitux> and stuff like that
[15:50] <Daemon404> multi-packet frames are common
[15:50] <Daemon404> so are multi-frame packets
[15:50] <Daemon404> ive written the The Decode Loop too many times...
[15:50] <Daemon404> low level api os low level
[15:50] <Daemon404> is*
[15:50] <nevcairiel> i kinda like it, gives me a lot of control :p
[15:50] <durandal_1707> huh?
[16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:a4e70918316c: avcodec/vcr1: return the actual number of consumed bytes
[16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:84b6451d29ec: avcodec/vcr1: simplify code, drop buf_size
[16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:f4e9c768d102: avcodec/vcr1: simplify code drop buf variable
[16:08] <Compn> michaelni : there were some talks about moving vcr1 and other codecs out of the main mpeg code
[16:08] <Compn> possibly theres some colorspace code still stuck in there as well
[16:08] <Compn> maybe you know about this already
[16:09] <durandal_1707> vcr1 have nothing to do with mpeg
[16:10] <cone-105> ffmpeg.git 03Paul B Mahol 07master:3dd4b6ea417a: lavfi: port phase filter from libmpcodecs
[16:10] <cone-105> ffmpeg.git 03Paul B Mahol 07master:916549cb1e73: lavfi/mp: remove mp=phase
[16:11] <Compn> oop, i mean vcr2 :)
[16:15] <Compn> only a hundred lines? blah
[18:03] <soul-d> probably not entirely ffmpeg question but still since they are "lowlevel" my questions http://pastebin.com/YEv5gwg3 + current wip chart http://i.imgur.com/2IioCPk.png
[18:03] <soul-d> did only get as fas finding the yuyv marker if vieuwed as hex
[18:04] <soul-d> simply said i need info on fileformats to be able to actualy write that files decoder
[19:03] <cone-105> ffmpeg.git 03Paul B Mahol 07master:605381281405: x86/simple_idct: use LOCAL_ALIGNED instead of DECLARE_ALIGNED
[19:10] <durandal_1707> how "Relicensed to LGPL with permission by all contributors." sounds like?
[19:22] <cone-105> ffmpeg.git 03Paul B Mahol 07master:771e2e59e2af: lavfi/hue: relicense to LGPL with permission by all contributors
[19:26] <durandal_1707> michaelni: can you kindly give permission to relicense mptestsrc to lgpl?
[19:28] <llogan> how was VDD?
[19:30] <llogan> durandal_1707: why do you want to relicense?
[19:31] <durandal_1707> to amuse rms
[19:32] <ubitux> :D
[19:32] <llogan> i don't know what rms means
[19:32] <ubitux> richard stallman
[19:32] <llogan> oh
[19:34] Action: michaelni politely refuses to annoy anyone
[19:34] <durandal_1707> :)
[19:35] <llogan> i'm surprised nobody asked why before giving permission
[19:35] <ubitux> lgpl is preferred
[19:35] <ubitux> overall codebase is lgpl
[19:35] <durandal_1707> we want to swith to AGPL
[19:36] <mateo`> :D
[19:38] <llogan> another "
[19:38] <llogan> Is this a family-friendly mailing list?"
[19:38] <llogan> in the queue from another chinese guy...
[19:38] <llogan> delete
[19:39] <Compn> hey llogan :)
[19:39] <Compn> vdd was fun
[19:40] <llogan> did you vandalize asterix statue with a ffmpeg sticker?
[19:40] <cone-105> ffmpeg.git 03Dirk Farin 07master:902a5fa7228d: avformat: H265 demuxer
[19:41] <llogan> oh, it's the same chinese guy.
[19:41] <michaelni> i hope you didnt forget giving asterix an umbrella in that case ;)
[19:42] <llogan> i was going to say since they are rain temporary then it won't cause permanent damage
[19:44] <nevcairiel> michaelni: since its rather likely that the fork will also get a H265 codec id, how do you plan on handling the change in numeric id?
[19:45] <ubitux> duplicate
[19:45] <michaelni> yes and remap_deprecated_codec_id()
[19:51] <Daemon404> what was the point of pushing that?
[19:53] <durandal_1707> of hevc raw demuxer?
[19:53] <Daemon404> yes
[19:54] <Daemon404> theres one coming from the actual person who wrote the hevc decoder
[19:54] <durandal_1707> to say: here, see! we have it!
[19:54] <Daemon404> yeah pretty much
[19:54] <Daemon404> seems dumb.
[19:54] <Compn> trolling openhevc to implement it
[19:54] <Compn> is my idea
[19:55] <kierank> durandal_1707: i thought you were going to be at vdd
[19:56] <Daemon404> he doesnt have a passport
[19:57] <kierank> could have taken the train
[19:57] <kierank> and gone through schengen countries
[19:57] <durandal_1707> yes, i were, big, handsome, strong guy in top left corner
[19:57] <Daemon404> if you mean https://twitter.com/flameeyes/status/374149289510838272/photo/1
[19:57] <Daemon404> then thats JEEB~
[20:02] <durandal_1707> are that all libav devs?
[20:02] <JEEB> nope
[20:39] <Compn> oh no, im in that picture
[20:40] <Compn> durandal_1707 : i'll give you a hint. i have the big beard
[20:42] <j-b> the biggest
[20:43] <Compn> its going to be a challenge to catch up to rms beard
[20:44] <llogan> you should do this: http://laughingsquid.com/wp-content/uploads/beard-20110516-120844.jpg
[20:44] <Compn> yes, the beard championships
[20:45] <cone-105> ffmpeg.git 03wm4 07master:060c6c464753: avformat/mpl2dec: handle files with CRLF linebreaks correctly
[20:45] <cone-105> ffmpeg.git 03Clément BSsch 07master:493ebbd7eb08: Update copyrights where my email appears with the new one.
[20:46] <Daemon404> Compn, you are no rms
[20:46] <Daemon404> at least, i didnt see you eat anything from your foot
[20:46] <JEEB> lol
[21:22] <cone-105> ffmpeg.git 03Clément BSsch 07master:30d40c9e866b: lavfi/drawtext: add generic timeline interface and deprecate "draw".
[21:27] <ubitux> ah shit, i unsubscribed my gmail address from ffmpeg-devel, so one mail from here awaits for moderation
[21:27] <ubitux> sorry about that
[21:31] <Compn> heh
[21:31] <Compn> no worries
[21:33] <Compn> ubitux: did you resubscribe ?
[21:33] Action: Compn approves ubitux mail
[21:34] <ubitux> i re-subscribed on my new address
[21:35] <ubitux> thx Compn
[21:57] Action: Compn lols about swear words post
[21:58] <Compn> llogan : why not discard that one ?
[22:05] <ubitux> so swscale has ppc, sparc and bfin asm, but no arm
[22:05] <ubitux> erm.
[22:20] <beastd> ubitux: no no, it is still spelled arm this days not erm ;)
[22:21] <ubitux> that's what i missed ;)
[22:24] <cone-105> ffmpeg.git 03Paul B Mahol 07master:d21e496cf5ae: lavfi/mptestsrc: use outlink->frame_count
[22:38] <llogan> Compn: because he was subscribed so it went though automatically. i thought it was weird so i added a mod bit to his address.
[22:38] <llogan> then i told him it was off-topic and the ML is not considered to be family friendly because it has nothing to do with families
[22:41] <llogan> Compn: oh...i see he sent another.
[22:43] <durandal_1707> Compn: you modded guy who trolled about swear words?
[22:47] <llogan> no, i did because i didn't know if it was some sort of pre-spam probe or whatever
[22:56] <gnafu> Wait, so did they think that the censorship was automated and not self-induced?
[00:00] --- Wed Sep 4 2013
1
0
[00:59] <joelogan> avconv -i input.ts -q 0 -filter:v setpts=2*pts out.ts
[01:00] <joelogan> did avconv change in this regard or does that look right
[01:00] <durandal_1707> this is not avconv help channel
[01:00] <joelogan> does such a thing exist
[01:10] <joelogan> can i record internet radio with ffmpeg?
[01:14] <durandal_1707> sure....
[04:17] <jangle_> greetings all. it seems that if I want to use libswscale, I neeed to also include libavutil/pxfmt.h in order to use the pixelformat enums required in the sws_getCachedContext call
[04:18] <jangle_> but I'm finding that after including the libswscale library, I'm getting linker errors
[04:18] <jangle_> that suggest that libswscale depends on other libraries in the ffmpeg project.
[04:26] <jangle_> its looking for av_free av_freep av_get_bits_per_pixel etc
[10:18] <kode101> i'm trying to record audio from an internet radio station
[10:18] <kode101> ffmpeg -i http://64.79.109.199:8010 -y -y 50 rec.mp3
[10:18] <kode101> but then i get an error such as
[10:18] <kode101> http://64.79.109.199:8010: Invalid data found when processing input
[10:19] <viric> double y ?
[10:19] <kode101> my mistake just yping here, the second y is a -t
[10:21] <kode101> this works in avconv but i'd much rather use ffmpeg
[10:22] <viric> I can't help.
[12:56] <[bjoern]> Using the same settings, every now and then ffmpeg produces mp4 files that my Android phone cannot seek properly (say, 42min video, seeking between 00:00:00 and 00:13:00 works fine, but if you try to jump to 00:20:00 it instead plays the video from the beginning).
[12:56] <[bjoern]> What can I do to debug this problem?
[12:59] <[bjoern]> (The videos do play back fine on Android)
[13:37] <[bjoern]> It also sometimes happens that in such videos you ask the player to seek to 00:30:00 and it jumps to 00:06:00 instead.
[13:37] <cbsrobot_> [bjoern]: does it happen with ffplay too ?
[13:38] <[bjoern]> Not with vlc on Windows, going to try ffplay now
[13:39] <cbsrobot_> try with: ffplay -show_streams
[13:40] <[bjoern]> With default options ffplay gives an "error while seeking" error message when seeking to certain points with frozen video and broken audio until you seek elsewhere.
[13:43] <[bjoern]> cbsrobot_, -show_streams seems to be a ffprobe, not a ffplay parameter, my copy of ffplay does not recognize it at least.
[13:44] <[bjoern]> http://dpaste.com/1364593/ is the output of ffprobe -show_streams for a sample file with seeking problems
[13:49] <[bjoern]> ffplay does not fail to seek to the same positions as the android player though, with a couple of ~42min videos it's fairly consistently at 12min where it starts failing
[13:54] <wawrek> How can I loop a video for a given amount of frames? -loop seems to work only with images
[14:17] <cbsrobot_> [bjoern]: sorry - I meant can you test with ffprobe -show_packets ?
[14:17] <cbsrobot_> maybe ffplay -show_packets works aswell
[14:18] <[bjoern]> That generates a lot of output, is there anything to grep for or would you like me to upload it somewhere?
[14:19] <cbsrobot_> well try to seek to the problematic part and see the dts pts values
[14:22] <cbsrobot_> [bjoern]: btw what version of ffmpeg do you use ?
[14:27] <[bjoern]> "ffmpeg version N-54643-g15cee5e built on Jul 11 2013 03:29:01 with gcc 4.7.3 (GCC)"
[14:43] <[bjoern]> I've recreated the video with -an no audio to see if the problem persists and shrinken the packet dump output, and the problem does indeed persist
[14:47] <[bjoern]> cbsrobot_, with the problematic videos I can seek to 11:54 but not to 12:xx on the android phone. Going through the -show_packets dts= and pts= values in the video stream around that point, I see nothing irregular.
[15:02] <[bjoern]> Encoding only the first 14 minutes does not change anything either, I guess next I'll try skipping the beginning
[15:16] <[bjoern]> Okay, I skip the first 10 minutes and then encode the next 14. Previously 12min+ was the unseekable part, so in the new video it should not be possible to seek past 2min+ if there was something in the input video at that position that causes the problem.
[15:17] <[bjoern]> But seeking there works fine
[15:17] <[bjoern]> But again, seeking past 12min in the new video (that position corresponds to roughly 22min in the input video) is not possible in the android player
[15:42] <[bjoern]> http://forum.doom9.org/showthread.php?t=158930 is fairly similar to my problem (he says 14min, I say 12min; he says crash/freeze, I say starts-over-playback-from-beginning)
[15:47] <Guest61994> Hello every body
[15:48] <Guest61994> is somebody here who can help me with ffmpeg. I have problem with audio/video sync when converting flv from red5 to mp4. I described problem here: http://stackoverflow.com/questions/18585607/red5-1-0-2-recorded-flv-convert…
[16:02] <[bjoern]> Fairly strong correlation between my problem and SAR/DAR values http://dpaste.com/1364721/
[16:02] <[bjoern]> What is the meaning of "[SAR 1:1 DAR 39:22], SAR 180224:180219 DAR 8192:4621" for the good ones?
[16:04] <[bjoern]> (I imagine the values in [] are rounded while the trailing ratios are the exact numbers?)
[16:04] <[bjoern]> Then the question would be why the "bad" inputs do not have the trailing values
[16:05] Action: [bjoern] reads http://www.mir.com/DMG/aspect.html
[16:22] <BallsDeep> Hey guys, I have a simple question: I convert a lot DTS streams to AC-3 using "ffmpeg". When this transcode is taking place, what format does the DTS decoder use"? Does it decode the DTS stream to PCM (RAW) or does it take the PCM (RAW) and place it into a WAV or AIF container?
[16:29] <BallsDeep> Hey guys, I have a simple question: I convert a lot DTS streams to AC-3 using "ffmpeg". When this transcode is taking place, what lossless format does the DTS decoder use"? Does it decode the DTS stream to PCM (RAW) or does it take the PCM (RAW) and place it into a WAV or AIF container before it is encoded to AC-3?
[16:32] <BallsDeep> Is there a switch I can use to see what "ffmpeg" is doing while it transcodes my DTS stream to an AC-3 stream? The -v switch does not give enough detailed information on what the DTS decoder is actually doing.
[16:36] <BoR0> hi. when building ffmpeg dylib's on Mac, everything is great. however when I try to build DLL's on Windows, I get make[1]: *** No rule to make target `libavdevice/avdevice.dll', needed by `all-yes`. Stop.
[16:37] <BoR0> static linking doesn't cause this issue. any thoughts?
[16:37] <BoR0> I get .a files but no .dll
[16:42] <BallsDeep> BoRo, I think we have 210 bots in this channel. Everyone is still sleeping.
[16:42] <spaam> BoR0: what? you need to show us some lins
[16:42] <spaam> BoR0: what? you need to show us some lines abouve that error message.
[16:42] <spaam> BoR0: use a pastebin for that
[16:43] <BallsDeep> I convert a lot DTS streams to AC-3 using "ffmpeg". When this transcode is taking place, what lossless format does the DTS decoder use"? Does it decode the DTS stream to PCM (RAW) or does it take the PCM (RAW) and place it into a WAV or AIF container before it is encoded to AC-3?
[16:44] <[bjoern]> BallsDeep, we've read your question a couple of times now.
[16:44] <BallsDeep> alright, thanks
[16:44] <spaam> np
[16:45] <BoR0> spaam, okay, here it is: http://pastebin.com/jTZtjAjL
[16:45] <BoR0> and this is the configure: ./configure --disable-doc --disable-ffmpeg --disable-ffprobe --disable-ffserver --disable-dxva2 --enable-runtime-cpudetect --disable-muxers --disable-bsfs --enable-openssl --disable-static --enable-shared. after that my script runs make
[17:34] <rurtle> @BoR0: I'm completely new to FFmpeg. However, from the log, it seems that you don't have pkg-config on your machine or not added to the path for some reason.
[17:35] <BoR0> unfortunately I tried with pkg-config as well, but no result
[17:36] <rurtle> Hmmm, weird
[17:36] <[bjoern]> Interestingly 2^14 / (23.98/second) is almost 12 minutes; that might be indicative of where the problem lies...
[17:52] <rurtle> Don't know if you have checked these already - http://ffmpeg-users.933282.n4.nabble.com/Hi-ffmpeg-gurus-does-the-latest-re… & http://www.gooli.org/blog/building-ffmpeg-for-windows-with-msys-and-mingw/
[18:07] <BoR0> rurtle, thanks but yeah I already went through those
[18:23] <Leoneof> hello, what to do with this error? http://devstation.org/978
[18:24] <saste> Leoneof, you need ancient ffmpeg libraries
[18:24] <saste> some of the required symbols were dropped since a few years
[18:25] <Leoneof> saste: good, where i can find this ancient ffpmeg lib?
[18:26] <Leoneof> sourceforge? :)
[18:26] <saste> Leoneof, http://ffmpeg.org/olddownload.html
[18:26] <saste> 0.5 or 0.6 may be good enough
[18:27] <saste> but note that we discourage the use of ancient libraries, for security reasons
[18:28] <Leoneof> :/
[18:28] <Leoneof> i need it for openwrt
[18:28] <Leoneof> thanks
[18:44] <[bjoern]> cbsrobot_, my problem, not being able to seek certain videos on android video player past ~12 minutes, appears to be related to the problematic videos having "2997003.00 tbn" while the good ones have values like "24k tbn" and "11988 tbn". Setting -r 23.98 (even though that's what they would come out with anyway) seems to fix the problem.
[19:15] <[bjoern]> And ... log(12 minutes times (2997003 per second))/log(2) is pretty much exactly 31
[20:13] <CentRookie> hi, i know it is old, but do you guys know if ogm is supported with ffmpeg 2?
[20:13] <CentRookie> i want to convert ogm files
[20:15] <klaxa> should be?
[20:15] <JEEB> as long as you don't seek you should be fine
[20:16] <JEEB> there's a bug on seeking on the trac
[20:16] <JEEB> https://trac.ffmpeg.org/ticket/2739
[20:27] <CentRookie> ok
[20:27] <BallsDeep> I convert a lot of DTS streams to AC-3 using "ffmpeg". When this transcode is taking place, what format does the DTS decoder use"? Does it decode the DTS stream to PCM (RAW) or does it take the PCM (RAW) and place it into a WAV or AIF container before it is encoded to AC-3?
[20:28] <CentRookie> when there an encoded video has a slow framerate and the audio seems to be moving faster than the image, but the original raw is fine, is it a problem with variable framerate?
[20:28] <CentRookie> *is
[20:29] <JEEB> unless you are trying in some weird way to put it into some CFR-only container and failing at it, it's not that
[20:29] <JEEB> VFR by itself should be OK
[20:30] <JEEB> BallsDeep, most lossy decoders output 32bit floating point PCM which is then pushed to the encoder
[20:31] <CentRookie> well i encoded a lot of videos, all to mp4 and just fine. but there are some outliers and i would like to know what makes them different
[20:31] <JEEB> can't say anything without knowing more specifics. No-one's an esper here
[20:33] <BallsDeep> Is there a switch I can use to see what "ffmpeg" is doing while it transcodes my DTS stream to an AC-3 stream? The -v switch does not give enough detailed information on what the DTS decoder is actually doing.
[20:33] <BallsDeep> [
[20:33] <BallsDeep> 2:36pm
[20:33] <BallsDeep> ]
[20:34] <CentRookie> http://pastebin.com/NW0JXPQY
[20:44] <CentRookie> found anything?
[20:44] <CentRookie> i think it might have to do with the gpac iso audio handler
[20:47] <CentRookie> ah it is the time base
[20:47] <CentRookie> is there anway to ignore the timebase from the container?
[20:50] <CentRookie> some genius set the tbn to 20000k
[20:50] <CentRookie> so 20m
[22:58] <pyBlob> I've got an instance of ffmpeg writing an mpegts-stream to stdout, this can be piped into ffplay, which works fine
[22:58] <pyBlob> how would I go for sending that stream over network and displaying it on another machine (with ffplay)
[23:14] <pyBlob> ... no one there?
[23:23] <Mavrik> pyBlob, pass a udp address as output? rtp? rtmp?
[23:23] <Mavrik> depends on which protocol you want to use and what is your use case.
[23:26] <pyBlob> I want a live stream that can be accessed from another machine ... preferably using rtp
[23:28] <Mavrik> RTP is really a PITA protocol
[23:28] <Mavrik> but you can set it as output
[23:28] <Mavrik> you'll get SDP on stdout
[23:33] <pyBlob> ... ok, now I get that ouptut: pastebin.com/n1yKS7mu
[23:36] <pyBlob> forgot to specify a port -.-
[23:44] <pyBlob> oh ... and you're right, rtp doesn't work correctly, using just udp is easier ._.
[23:48] <joske> hello. i have a question about packet loss. how do i let the audio decoder know i have a lost packet? i can't feed anything to avcodec_decode_audio4...
[23:49] <Mavrik> joske, you don't, you just feed it the next one
[23:49] <Mavrik> PTS will jump and that's i
[23:49] <Mavrik> t
[23:50] <joske> then the next audio frame will be LONGER?
[23:51] <joske> i'm using the Opus codec, which should recover that lost frame partlialy with data from the previous frame
[23:52] <joske> it's for a VOIP application, so waiting for the next packet means i don't have any audio to play at all
[23:55] <Plorkyeran_> passing a frame with null data/zero length may work
[23:55] <Plorkyeran_> unless it gets handled by something in lavc rather than making it to libopus
[23:55] <Mavrik> joske, why would be longer?
[23:56] <Mavrik> you TELL the decoder what the timestamp of packet is
[23:56] <Plorkyeran_> if that's the case you'd probably have to use libopus directly to use its error concealment
[23:56] <Mavrik> why would you get longer output?
[23:56] <Mavrik> (unless the decoder does something really dumb)
[23:56] <joske> because something needs to take up the time, or else it gets out of sync
[23:56] <Mavrik> and that something isn't the decoder
[23:57] <Mavrik> you'll get back decoded frame with proper timestamp
[23:57] <Mavrik> if you lost a frame, that's your problem
[23:57] <joske> yes, but if i lost the frame i have no audio to play back
[23:57] <Mavrik> decoder doesn't care as long as it can do its job ;)
[23:57] <Mavrik> tough.
[23:57] <Plorkyeran_> opus has overlapped frames with error recovery
[23:57] <joske> instead of a reconstructed frame
[23:57] <Plorkyeran_> to handle dropped packets
[23:57] <Mavrik> Plorkyeran_, that'll be handled internally by decoder then.
[23:58] <Plorkyeran_> you have to explicitly pass null packets to libopus
[23:58] <Plorkyeran_> in place of missing packets
[23:58] <joske> according to Opus documentation: "Lost packets can be replaced with loss concealment by calling the decoder with a null pointer and zero length for the missing packet."
[23:58] <joske> which i can't do via ffmpeg, as it will segfault
[23:59] <Plorkyeran_> lavc's wrapper for libopus is dreadfully simple
[23:59] <Plorkyeran_> if you know that the audio will always be opus then just using libopus directly is probably not a big deal
[00:00] --- Wed Sep 4 2013
1
0
[01:19] <cone-108> ffmpeg.git 03Carl Eugen Hoyos 07master:e337c9d56408: Read h264 headers from v4l2 to allow stream-copying.
[01:19] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:cf9429944892: Merge remote-tracking branch 'cehoyos/master'
[01:35] <cone-108> ffmpeg.git 03Marton Balint 07master:b339dccbba87: lavc: add teletext decoder using libzvbi
[04:47] <cone-158> ffmpeg.git 03Michael Niedermayer 07master:cdd5df8189ff: avfilter/vf_fps: make sure the fifo is not empty before using it
[04:51] <BBB> ubitux: yes only 32x32 tx and smaller for 64x64 prediction blocks
[04:52] <BBB> ubitux: there is no 64x64 tx
[04:52] <BBB> ubitux: I wrote one, but it didn't work so well so we decided to ditch it
[04:52] <BBB> (probably a bug and not enough time to debug it)
[08:36] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07master:ec8a4841f7e8: Avoid a deadlock when decoding wma.
[10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/0.10:f4392277b02e: Avoid a deadlock when decoding wma.
[10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:a5ef62ede16a: Avoid a deadlock when decoding wma.
[10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:7599284ad349: Avoid a deadlock when decoding wma.
[10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:c93874c3a8f8: Avoid a deadlock when decoding wma.
[10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:7eee79ea2fd3: Avoid a deadlock when decoding wma.
[10:11] <cone-52> ffmpeg.git 03Michael Niedermayer 07release/2.0:1da5ab751f99: avcodec/ffv1dec: move initial_states init to init_thread_copy()
[10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/2.0:8e1760f37f7a: avcodec/ffv1dec: reorganize thread init/update
[10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/2.0:f5a4bd23e9ae: Avoid a deadlock when decoding wma.
[12:38] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:62d07bb321a9: avcodec/pnmdec: use a more specific pointer type than void in samplecpy()
[12:38] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:4fb3e1a652a9: avcodec/pnmdec: fix unaligned read
[15:06] <j-b> 'morning
[15:11] <michaelni> morning
[15:58] <av500> #ffmpeg-logspam anybody?
[16:00] <durandal_1707> hmm, doesn't sound that bad
[16:52] <michaelni> BuxiNess, there are some jpeg2000 patches on ffmpeg-devel
[16:52] <michaelni> do you have time to review them ?
[16:56] <michaelni> mateo` / ubitux can one of you review " [FFmpeg-devel] [PATCH] avformat/movenc: Use the rate from av_timecode_init_from_string() for tmcd" ?
[16:56] <michaelni> its only a 1 line change
[16:57] <ubitux> michaelni: did you look how timecode track from quick time products look like?
[16:57] <ubitux> typically take the mov from big buck bunny
[16:57] <ubitux> there is a tmcd track generated with one of the reference software
[16:57] <JEEBsv> ubitux: btw were you at VDD?
[16:57] <ubitux> JEEBsv: yes
[16:58] <JEEBsv> :< didn't happen to meet you
[16:58] <JEEBsv> oh well
[16:58] <ubitux> :(
[16:59] <michaelni> ubitux, i dnt understand what you suggest
[17:00] <michaelni> is the code right is ot wrong or you dont care ?
[17:00] <ubitux> i was wondering if it was affecting the output, but since there is no fate change i guess it's not
[17:00] <ubitux> so forget my comment
[17:00] <michaelni> the bug is about a large number being stored in a 8bit field
[17:01] <durandal_1707> where?
[17:01] <michaelni> or rather it causing an error and half a tag being stored
[17:01] <michaelni> tmcd tag
[17:01] <BuxiNess> michaelni, yep I know, I'll do that
[17:01] <michaelni> BuxiNess, thx
[17:02] <BuxiNess> but right now short in time
[17:02] <michaelni> ubitux, my bugfix tries to fix it by favoring the average fps instead of the timebase for the tmcd tag
[17:02] <michaelni> that way it fits in 8bit (as value of 30)
[17:02] <michaelni> i dont know if this can have side effects
[17:03] <michaelni> QT certainly stores 30 in there because larger values dont fit
[17:03] <michaelni> like 299 2997 30000 or whatever
[17:05] <ubitux> wont this affect the written nb_frames?
[17:06] <ubitux> those values are likely irrelevant anyway but well
[17:07] <michaelni> yes, the code tried ro store nb_frames=30000 with avio_w8()
[17:08] <ubitux> oh that's what you fix
[17:08] <ubitux> well i guess that's ok
[17:19] <michaelni> ubitux, ok & thanks
[17:23] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:2501f6d3d6b6: avformat/movenc: Use the rate from av_timecode_init_from_string() for tmcd
[18:03] <j-b> btw, where is the aac encoder bugtrack?
[18:14] <ubitux> heh i just lost 2 hours debugging a compilation issue because of http://trac.ffmpeg.org/ticket/1783
[18:14] <ubitux> :(
[18:18] <ubitux> (not with android, just cmake & c++)
[20:17] <Daemon404> 30
[20:17] <Daemon404> woops
[20:25] <durandal_1707> ubitux: i think that s/random/s lavfi patch you did is good idea
[20:25] <ubitux> what?
[20:25] <durandal_1707> the most boring ever branch
[20:25] <ubitux> ow lol
[22:01] <cone-52> ffmpeg.git 03Vignesh Venkatasubramanian 07master:fdd1aaf87aae: avpacket: Fixing side data copy when src == dst
[23:02] <Daemon404> michaelni, my fate boxes should be up again some time this week, fyi
[23:03] <michaelni> Daemon404, ok & thanks
[23:23] <BBB> ubitux: pingpong
[23:27] <ubitux> BBB: pongping
[23:31] <BBB> ubitux: ah goos
[23:31] <BBB> s/s/d/
[23:32] <BBB> ubitux: so, is 4x4_idct ok as a starter for you? it's quite straightforward since the vp8 one is quite similar, and serves as a nice start for larger ones, such as multiple 4x4s at a time (see ffh264; we never did this for vp8, so that's another way to optimize ffvp8), and also do 8x8/16x16/32x32 or any of the adst variants
[23:32] <ubitux> yes sorry i didn't reply to your pm
[23:32] <ubitux> sure it's fine with me
[23:33] <BBB> ubitux: ok cool; so I'm working on making emu-edge work fully, and will then do mc and loopfilter
[23:33] <ubitux> thought i got my first full time day work today so, i'm gonna lack some time
[23:33] <BBB> then whoever finishes first can do mt
[23:33] <BBB> that's fine, so will I
[23:33] <BBB> optimization is less important in terms of time
[23:33] <BBB> we can submit this as-is since it passes fate w/o emu-edge
[23:33] <ubitux> this sentence out of context is weird ;)
[23:33] <BBB> and the code isn't super-ugly
[23:34] <BBB> hm right
[23:34] <BBB> now that I re-read it
[23:34] <ubitux> i think we need to change the assert & mark the codec as experimental before pushing i think
[23:35] <ubitux> but maybe i think too much
[23:36] <durandal_1707> so how much that missed thing in ffvp8 could increase speed?
[23:38] <BBB> why experimental?
[23:38] <BBB> it works on all samples and has no known security issues
[23:39] <BBB> unless you want to prefer libvpx until simd is done?
[23:39] <BBB> I don't think that's what experimental means
[23:39] <BBB> because experimental means it won't use it w/o libvpx enabled
[23:39] <BBB> unless you use -strict -2 or so
[23:41] <ubitux> well im just afraid of ppl requesting optims asap
[23:41] <ubitux> also i dont remember any official vp9/libvpx announce
[23:41] <ubitux> and maybe such a big codec needs more testing before marking it "final"
[23:42] <ubitux> i won't insist much on this, 'just my opinion
[23:42] <durandal_1707> if i do not use loopfilter=all i get bus error whan playing vp8 (when compiled with clang3.3)
[23:43] <durandal_1707> ubitux: there is code coverage just for that reason
[23:45] <BBB> durandal_1707: file a bug or so, I haven't tested that for a while, maybe it broke
[23:45] <durandal_1707> no, its some clang silly thing
[23:48] <durandal_1707> gdb says (its far from useful on my system) that it crashes in ff_simple_idct_add_mmx
[23:50] <durandal_1707> hmm this could be DECLARE/LOCAL aligned thing...
[23:55] <durandal_1707> actually, is there any difference between two?
[23:57] <BBB> yes
[23:57] <BBB> DECLARE_ALIGNED is for heap
[23:57] <BBB> LOCAL_ALIGNED is for stack
[23:58] <BBB> rather, DECLARE_ALIGNED is for members in structs that by themselves are already aligned
[23:58] <BBB> e.g. if a struct is 16byte aligned, then DECLARE_ALIGNED(16, type, member)[size]; means that struct member is also 16 byte aligned
[23:58] <BBB> LOCAL_ALIGNED_16(type, name[size]); is for stack arrays
[23:59] <BBB> why does vp8 end up in ff_simple_idt_add_mmx?
[23:59] <BBB> vp8 has its own idct
[23:59] <durandal_1707> line in 80 of libavcodec/x86/simple_idct.c use DECLARE...
[00:00] --- Tue Sep 3 2013
1
0
[00:07] <Guest55224> I'm having some trouble compling 0.10.8 -- it's related to not finding libx264.a (which is clearly present). The error is at : http://pastebin.com/nZeSzda9
[00:07] <Guest55224> This is on CentOS 5.9 64-bit
[00:08] <klaxa> 0.10.8 is horribly outdated
[00:09] <Guest55224> I know that, but our internal devs need this version (for whatever reason).
[00:11] <Guest55224> The installation process in x264 is not standard - you have to select from several... lib-static lib-shared cli install-lib-dev install-lib-static install-lib-shared install-cli. Install "all" doesn't do much. I don't understand why they do this -- and I wonder if I'm missing something from the installation. The pastebin shows that the library is clearly there.
[00:17] <braincracker> http://vimeo.com/8143217 impress the pharaoh with iphone ;>>
[04:01] <davesa> Hi, does ffmpeg by default enable vaapi for hardware acceleration? or i have to compile it with --enable-hwaccel=h263_vaapi --enable-hwaccel=h264_vaapi
[04:01] <davesa> --enable-hwaccel=mpeg2_vaapi --enable-hwaccel=mpeg4_vaapi? or this old?
[04:28] <davesa> please can anyone help me out with ffmpeg on ubuntu
[04:32] <grepper> Its better to just ask your question and hang around. If someone can answer they will.
[04:33] <grepper> maybe I missed it and you already did though
[04:36] <davesa> yes
[04:36] <davesa> i will resend
[04:36] <davesa> i am newbie to ffmpeg
[04:37] <davesa> and trying to do encoding anf decoding, but i was thinking of using hardware acceleration
[04:37] <davesa> is that possible?
[04:37] <davesa> i read online everywhere no complete information
[04:37] <davesa> and some says we have to build with --enable-vaapi
[04:38] <davesa> and some says no need with new ffmpeg as it use the libav libraries
[04:38] <grepper> I think so, using vdpau (for my nvidia)
[04:38] <davesa> hmmm
[04:38] <davesa> because i have i7 4770k
[04:38] <davesa> and it support intel quick sync
[04:39] <davesa> and has intel graphic card.
[04:39] <davesa> do you think i can enable ffmpeg to use intel quick sync new technology
[04:40] <grepper> dunno
[04:40] <davesa> intel media sdk for linux has been removed from there site, i was thinking of looking at it to see if anything can be done
[04:41] <grepper> hm, I was thinking of mplayer
[04:41] <davesa> but when you use vdpau , is it only for nvidia?
[04:42] <grepper> yeah, I think vdpau is nvidia. but I really don't think gpu encoding with speed things up based on some things I've randomly read. I'm not expert and I've never really tried. My core i5 is plenty fast enough :)
[04:42] <davesa> i got lost when i went and read online
[04:42] <davesa> heheehe
[04:42] <klaxa> GPU decoding is... well not really usable as it is
[04:42] <davesa> its really ot much info,
[04:43] <davesa> what about hardware acceleration?
[04:43] <klaxa> with OpenCL the GPU can be used for so-called "lookahead-threads" with x264
[04:43] <klaxa> but that's all i know
[04:43] <davesa> aha
[04:43] <klaxa> no idea what a lookahead-thread is actually
[04:44] <davesa> i will google that
[04:44] <davesa> :)
[04:44] <davesa> do you know how to enable fmpeg or x264 to use hardware acceleration?
[04:44] <klaxa> hardware acceleration for encoding? forget it
[04:45] <klaxa> hardware acceleration for decoding? it's possible, but it's also pointless
[04:45] <klaxa> at least if you are doing an encode that is sophisticated and takes a while
[04:46] <klaxa> in that case decoding of the frame is not really worth optimizing afaik
[04:47] <davesa> ok, i start reading about lookahead x264
[07:13] <vulture-> for a 50 fps video, why would the video decoder's context time_base num=1 den=100 ?
[07:14] <vulture-> seems like for most .avi's I've encoded myself it's correct (e.g. 1001 / 30000) but for mp4's and youtubes its more like twice what it should be
[09:15] <bigbox30> I need help:
[09:15] <bigbox30> between Lavf55.12.102 and Lavf55.15.100 MKVs muxed with FFMPEG stopped playing on my standalone.
[09:15] <bigbox30> any idea what changed and how i switch it back?
[09:16] <saste> bigbox30, are you able to git bisect in order to find the flawed commit?
[09:17] <bigbox30> not really no.
[09:17] <bigbox30> i mean possibly.
[09:17] <bigbox30> i don't really want to recompile it
[09:17] <bigbox30> i'm just a user.
[09:18] <saste> what's you standalone player?
[09:18] <saste> *your
[09:18] <bigbox30> LG bluray player.
[09:18] <bigbox30> it dosn't like compressed MKV headers
[09:18] <bigbox30> but ffmpeg has never been a problem
[09:19] <bigbox30> i basically batch remux all my mky using ffmpeg
[09:19] <bigbox30> then all of a sudden this weekend it stops playing them
[09:19] <saste> check the log if there is something which may have been affected MKV remuxing
[09:20] <bigbox30> where? this is the only change log i see.
[09:20] <saste> but the fastest way to tell is probably to git bisect, since you are the only one who can test the problem
[09:21] <bigbox30> well i wondered if maybe something like reserve_index_space had now been made default.
[09:25] <felixhandte> Anyone here? I'm having a problem mapping streams.
[09:26] <bigbox30> well i'm here but very much on the needing help side of things
[09:26] <bigbox30> not so much with the giving
[09:26] <felixhandte> Specifically, DaVinci Resolve puts out a
[09:26] <felixhandte> he
[09:26] <felixhandte> heh*
[09:30] <Mavrik> felixhandte, what seems to be the issue
[09:33] <felixhandte> so, I'm exporting from Resolve into a .mov
[09:33] <felixhandte> and
[09:35] <felixhandte> resolve's mov has 3 streams, the video (DNxHD 185), audio (pcm_s24le), and a weird third stream, marked tmcd
[09:35] <felixhandte> so
[09:35] <felixhandte> i'm trying to replace the audio in that clip with the separate audio recording
[09:36] <Mavrik> ah
[09:36] <felixhandte> with, e.g., ffmpeg -i RESOLVE_CLIP.mov -i AUDIO.wav -map 0:0 -map 1:0 -vcodec copy -acodec copy OUTPUT.mov
[09:36] <felixhandte> and
[09:36] <Mavrik> which part of it doesn't work? can you paste command line and output to a pastebin?
[09:37] <felixhandte> sure
[09:39] <felixhandte> ... one sec
[09:42] <felixhandte> Mavrik: http://pastebin.com/yA8yS6g3
[09:43] <Mavrik> ok, I see it
[09:43] <Mavrik> what's the actual issue?
[09:43] <felixhandte> well
[09:43] <felixhandte> though i'm not asking for it
[09:43] <felixhandte> you can see, in the output file
[09:43] <felixhandte> at the bottom
[09:43] <felixhandte> that i'm getting this third pseudo-stream
[09:43] <felixhandte> "stts"
[09:43] <felixhandte> which
[09:44] <felixhandte> normally i wouldn't care about
[09:44] <felixhandte> but Avid is pitching a fit if it's there
[09:44] <Mavrik> hmm, looking at the mov spec
[09:44] <Mavrik> it seems like an atom you'd need because you have raw wav in it
[09:44] <Mavrik> it's a time/sample mapping
[09:45] <felixhandte> ah
[09:45] <Mavrik> but it's wierd it doesn't show up in source
[09:45] <felixhandte> ok
[09:45] <felixhandte> now, if i then do ffmpeg -i OUTPUT.mov -vcodec copy -acodec copy OUTPUT_NEW.mov
[09:46] <felixhandte> that stream disappears
[09:46] <felixhandte> so
[09:46] <Mavrik> looking at the source
[09:46] <felixhandte> i can work-around that way
[09:46] <felixhandte> but
[09:46] <felixhandte> preferably i wouldn't have to
[09:46] <Mavrik> it seems ffmpeg always writes the stts atom
[09:46] <Mavrik> hmm
[09:47] <Mavrik> felixhandte, I'd say that's something that goes on ffmpeg bug tracker :)
[09:47] <felixhandte> heh
[09:47] <felixhandte> cool
[09:47] <Mavrik> it looks like a bug when writing sttc
[09:47] <Mavrik> probably wrong stream mapping or something
[09:47] <felixhandte> are you going to file it, or shall i?
[09:48] <felixhandte> (i'd be happy to, but i'd have to figure out how)
[09:48] <Mavrik> sorry, at the office now, don't have time to investigate it :/
[09:48] <felixhandte> ok
[09:48] <felixhandte> no problem
[09:48] <Mavrik> if you have time you can post on trac.ffmpeg.com
[09:49] <Mavrik> http://ffmpeg.org/bugreports.html
[09:49] <felixhandte> alright
[09:49] <felixhandte> i'll see if i can do that
[09:50] <felixhandte> i gotta get this stuff into avid first though :(
[09:50] <felixhandte> many thanks for your help!
[10:57] <yaron> Hi, l like to have a little advice. My goal is it to write a rtp stream to a local filesystem als hls "stream" just by "copy" the data. Under OSX it worked by using "ffmpeg -i rtp://@:5004 -qscale 2 -mbd 2 -scodec dvbsub -flags -global_header -hls_time 10 -hls_list_size 6 -hls_wrap 10 -start_number 1 mystream.m3u8" fine. But i struggle since several days to do the same thing under iOS.
[11:00] <yaron> As fare as I unterstand, there is no ios code which can give me the same interface like the OSX ffmpeg binary right ?
[12:15] <wodim> hello. i'm using -itsoffset -13.5 to synchronise a/v in a .mkv file. unfortunately this means the beginning of the movie has no video at all. how do i fill the beginning of the new movie with black frames?
[13:40] <bigbox30> anyone know about any changes to libavformat between Lavf55.12.102 and Lavf55.15.100 that would stop MKV working on my hardware player?
[13:42] <durandal_1707> no
[13:43] <bigbox30> :(
[13:43] <bigbox30> is there a changelog at all
[13:43] <durandal_1707> yes there is
[13:43] <bigbox30> ...
[17:16] <XwZ> does anyone have a problem with closing an rtsp link ? I close the link with avformat_close_input and the teardown message is sent but the camera don't release the slot
[17:16] <XwZ> do you have an idea ?
[17:17] <XwZ> I use avcodec_close and avformat_close_input to clean everything
[18:26] <Renich> hey guys
[18:27] <Renich> http://paste.fedoraproject.org/36539/37813921/
[18:27] <Renich> I want to record a screencast and join two audio sources. Basically, alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00-CODEC.analog-stereo.monitor and alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00-CODEC.analog-stereo
[18:27] <Renich> can anybody help me out with this?
[18:28] <durandal_1707> what are those files?
[18:28] <Renich> durandal_1707: pulseaudio sources
[18:29] <Renich> durandal_1707: http://paste.fedoraproject.org/36540/13781393/
[18:30] <durandal_1707> you want to concatenate them or?
[18:30] <Renich> durandal_1707: yes, I do
[18:30] <durandal_1707> you record them into same codec and container and later use concat demuxer
[18:31] <Renich> durandal_1707: I am making a screencast on pianoteq; a synth piano which rocks, and I need to record that (software generated) and my voice (through card)
[18:31] <Renich> durandal_1707: ok, how do I do that?
[18:32] <durandal_1707> how to do what exactly?
[18:33] <Renich> durandal_1707: well, record the audio into independent files and concat them after
[18:33] <Renich> durandal_1707: can ffmpeg save the two audio streams into separate files and the video into another one?
[18:34] <durandal_1707> yes
[18:34] <Renich> durandal_1707: ok, how do I do that exactly?
[18:34] <durandal_1707> it is explained in documentation
[18:34] <Renich> durandal_1707: ok
[19:55] <elfinit> Hello
[19:58] <elfinit> I am looking at https://github.com/dickontoo/omxtx/blob/master/omxtx.c. At line 386 the codec is set to CODEC_ID_H264. Now, I want to specify crf option of H264. I think i have to use X264Context, but I dont know how to access this structure from the general AVCodec structure.
[20:04] <durandal_1707> elfinit: you use av_opt_set
[20:08] <elfinit> durandal_1707: I assume the property name is just crf
[20:11] <durandal_1707> elfinit: i assume its mentioned in source code
[20:12] <durandal_1707> you can just use AVDictionary and set key = value as options
[20:13] <durandal_1707> or use av_opt_set_double() for crf
[20:35] <kode101> ayo
[20:35] <kode101> why is this reducing my video quality so much
[20:35] <kode101> 'ffmpeg','-i',tmpdir+'tmp-s.ts','-filter:v','setpts='+str(videostretch)+'*PTS',tmpdir+'slow.ts','-loglevel','quiet'
[20:37] <kode101> wait no nevermind
[20:37] <kode101> how can i retain quality when stripping audio from a video
[20:37] <kode101> oh doi
[20:38] <kode101> vcodec copy
[20:42] <elfinit> hmm, av_opt_set_double with name = "crf" applied to AVCodecContext does not have any effect
[20:43] <durandal_1707> elfinit: you apply it to encoder private context not AVCodecContext
[20:43] <durandal_1707> elfinit: see doc/examples/*
[20:44] <durandal_1707> anyway av_opt_set_dict is the most generic way to set codec options
[20:44] <kode101> why is my video blocky when i use -filter:v and setpts=0.5
[20:45] <durandal_1707> blocky?
[20:45] <kode101> yeah it looks all mpeggy?
[20:45] <kode101> i have a really clean ts thats 3 seconds long, i want that but 6 seconds long
[20:45] <durandal_1707> i still dunno what you are talking about
[20:45] <kode101> whats the best way to slow the video down at the highest possible quality
[20:46] <kode101> a video that has no audio
[20:46] <durandal_1707> setpts=0.5 certainly is not solution
[20:46] <kode101> haha
[20:46] <kode101> i see!
[20:46] <kode101> :)
[20:46] <kode101> how should I approach slowing the video down so?
[20:48] <zap0> ffmpeg -r 2 -i cock.avi balls.avi
[20:48] <kode101> i like your style zap0
[20:48] <zap0> try it.
[20:50] <durandal_1707> kode101: did you read setpts documentation?
[20:51] <kode101> is cock the input file there zap0
[20:52] <zap0> yes
[20:53] <kode101> what does -r refer to
[20:53] <kode101> 'rate'?
[20:53] <kode101> no durandal_1707 i did not i just been googling ffmpeg slow down video
[20:55] <durandal_1707> kode101: you really should, there are examples to slow down or speed up
[20:56] <zap0> do you think guessing things by choose a word that starts with teh same letter is really a good way to do things?
[20:57] <kode101> yeah if googling ffmpeg -r returns nothing and the guy who told me to use rate is right there
[20:57] <kode101> mr cock and balls
[21:00] <zap0> why are you using an advertising companies advert listings as a technical reference. do you watch the shopping channel when you want know something?
[21:01] <kode101> yes like what to purchase
[21:01] <kode101> such as swords or jewels
[21:01] <kode101> anyway my main deal is, having looked at the setpts documentation now
[21:02] <zap0> mmmm... i wonder how many types of fish there are in the black sea... I know! i'll turn on the shopping channel.
[21:02] <kode101> you have lacerated me by using your wit
[21:03] <zap0> i'm sure there is a remedy for that, on teh shopping channel.
[21:03] <durandal_1707> zap0: no you would contact wikipedia
[21:03] <kode101> durandal, what am i neglecting here:
[21:03] <zap0> wikipedia... a blog setup by a pornographer. what a great reference!
[21:04] <kode101> ffmpeg in.ts -filter:v setpts='0.5*PTS' out.ts
[21:04] <kode101> apart from the -i at the start ;)
[21:06] <kode101> can i fit a -vcodec copy in there?
[21:06] <zap0> there are more people failing with setpts stuff than successeeding. there must be a reason.
[21:06] <durandal_1707> kode101: no
[21:07] <durandal_1707> kode101: 0.5 speeds up
[21:08] <kode101> oh yeah apart from that aswell, the point is that the result comes out very artefacted
[21:08] <kode101> while the input file, though too fast, is much cleaner
[21:08] <kode101> so as i understand i am encoding it in a lossy manner but don't know how that relates to setpts
[21:09] <kode101> since it's one line
[21:09] <kode101> ffmpeg -i in.ts -filter:v 'setpts=2*pts' out.ts
[21:09] <kode101> it slows it down just fine, just the result is very artefacted
[21:10] <durandal_1707> because default mpegvideo paramters are retarded
[21:10] <kode101> haha boosh there it is
[21:11] <durandal_1707> anyway this is doing transcoding...
[21:11] <kode101> ok ok fresh i'm down, so i'm not specifying a decent enough transcode setting for the setpts command?
[21:12] <durandal_1707> no, what are you trying to archieve(slow down) is transcoding
[21:13] <durandal_1707> there is no way to do same with -c:v copy
[21:13] <durandal_1707> so you are just doing this for fun, or what?
[21:14] <kode101> yeah a project
[21:14] <durandal_1707> well try adding '-q 0' after filter params
[21:15] <zap0> -r slows things down.
[21:15] <kode101> zap0 slows things down
[21:15] <kode101> *audience goes wild
[21:15] <zap0> -q [low number] make better quality
[21:15] <durandal_1707> -r have documentation
[21:16] <durandal_1707> -r rate set frame rate (Hz value, fraction or abbreviation)
[21:16] <zap0> or you could keep guessing at setpts
[21:16] <durandal_1707> there is nothing guessing in setpts
[21:17] <durandal_1707> you just need ot understand presentation timestamp and stream time base concept
[21:19] <kode101> ok cool
[21:19] <kode101> can i express the -r value as a speed relative to the input file
[21:19] <kode101> -r [half speed]
[21:19] <kode101> or do i need to calculate that first
[21:19] <kode101> via querying its framerate
[21:26] <zap0> query
[21:26] <zap0> -r is a set value (as far as i know)
[21:27] <zap0> kode101, http://ffmpeg.org/ffmpeg.html#Generic-options section 5.5 Video Options. 2nd item
[21:29] <kode101> hmm
[21:30] <kode101> durandal_1707 how would i include -q 0 there
[21:30] <kode101> -filter:v -q 0?
[21:31] <kode101> ffmpeg -i in.ts -filter:v -q 0 'setpts=2*pts' out.ts
[21:31] <zap0> kode101, -q 0 is a single param you've stuck it inside the -filter:v '...' which is a single param
[21:32] <zap0> move -q to before -filter
[21:32] <kode101> and the 0?
[21:32] <DuelShark> hi all - glad to see this channel exists! don't suppose anyone has a tip on making ffmpeg as fast as possible. Using preset ultrafast currently and 8 threads, any help appreciated
[21:32] <zap0> like this ffmpeg -i in.ts -q 0 -filter:v 'setpts=2*pts' out.ts
[21:32] <zap0> kode, yes, and the 0
[21:32] <kode101> safe
[21:32] <kode101> trying it now
[21:33] <leandrosansilva> Hello to all. I'm having some problems decoding h264 streams. In fact in my application (I'm using ffmpeg-1.2.3 on a C++ application on Ubuntu Linux 64-bit) I decode, simultanously 4 different streams. I'm often having errors to decode these streams. They come from high resolution IP Cameras:
[21:33] <leandrosansilva> http://pastebin.com/NrgGxSg3
[21:33] <zap0> -filter:v 'setpts=2*pts' <-- all that is a single parameter, don't stick things inside it ;)
[21:34] <kode101> ohhhh
[21:34] <leandrosansilva> (the transport is rtsp over tcp)
[21:34] <kode101> thanks zap0
[21:35] <kode101> is there a quality& below 0
[21:35] <kode101> *checks around to make sure no police are nearby
[21:35] <zap0> kode101 there is likely no quality below 2 for most encoders.
[21:35] <kode101> the premium quality...
[21:35] <kode101> ultimate lossless...
[21:35] <zap0> so 0,1,2 are (for most encoders) the same.
[21:39] <kode101> safe
[21:39] <kode101> it looks great now
[21:39] <kode101> thanks yall
[21:39] <zap0> :)
[21:44] <kode101> so if i have a .ts
[21:44] <kode101> whats the highest quality mp4 encoding i can give it
[21:45] <durandal_1707> lossless with x264 encoder
[21:45] <kode101> what's that look like
[21:45] <kode101> command wise
[21:48] <kode101> ffmpeg -i input -c:v libx264 -preset veryslow -qp 0 output.mkv
[21:48] <klaxa> if you want to wait forever, use veryslow
[21:48] <klaxa> if you want to wait forever and 3 days, use placebo
[21:48] <klaxa> but yeah that'd probably be lossless
[21:49] <klaxa> but it will probably be even larger than the .ts
[21:50] <durandal_1707> preset is meaningless with lossless
[21:50] <klaxa> not really afaik
[21:50] <durandal_1707> and lossless should be faster than placebo
[21:50] <klaxa> but i might be wrong
[21:51] <kode101> ah trying ultrafast
[22:34] <Adrellias> hey guys quick question
[22:35] <Adrellias> when i try and use x264 with ffmpeg with lossless_ultrafast
[22:35] <Adrellias> i get a error where it cannot find the preset
[22:35] <Adrellias> i also do not see the preset in /usr/share/ffmpeg
[22:36] <klaxa> just use -preset ultrafast -qp 0
[22:38] <Adrellias> klaxa: ultrafast is also not in /usr/share/ffmpeg
[22:38] <Adrellias> tried both
[22:38] <klaxa> what version are you running?
[22:38] <Adrellias> could you paste bin your ultrafast preset for me ?
[22:39] <Adrellias> let me check
[22:39] <klaxa> the use of -vpre is deprecated
[22:39] <klaxa> ultrafast is a preset of x264
[22:39] <klaxa> read the topic please :/
[22:39] <Adrellias> media-video/ffmpeg-1.0.7
[22:39] <Adrellias> x264 use flag is enabled
[22:39] <klaxa> what is your command line?
[22:39] <klaxa> can you pastebin what you execute alongside with the complete output of ffmpeg?
[22:40] <Adrellias> yep gime a second
[22:40] <jned> When I try: ffmpeg -f v4l2 -s 320x240 -r 25 -i /dev/video0 -f alsa -ac 1 -i hw:0 http://localhost:8090/feed1.ffm I get TCP connection to localhost:8090 failed: Connection refused
[22:41] <klaxa> did you start ffserver?
[22:42] <Adrellias> klaxa: http://pastebin.com/raw.php?i=Fsf2yhv2
[22:42] <klaxa> <klaxa> just use -preset ultrafast -qp 0
[22:42] <klaxa> so the whole command line would be:
[22:42] <Adrellias> klaxa: bleh copied the wrong line
[22:42] <klaxa> ffmpeg -f alsa -ac 2 -ab 192k -i pulse -f x11grab -s 1366x768 -r 30 -i :0.0 -acodec pcm_s16le -vcodec libx264 -preset ultrafast -qp 0 -threads 0 test.mkv
[22:42] <jned> klaxa, thx man, now its running, so how do I view it? When I goto localhost:8090/feed1.ffm it says "This fee is already being received"
[22:43] <klaxa> that is defined within ffserver
[22:43] <klaxa> the config file of ffserver
[22:43] <Adrellias> klaxa: http://pastebin.com/raw.php?i=hv7JbDja
[22:43] <klaxa> don't use -vpre
[22:43] <Adrellias> klaxa: so just preset ?
[22:44] <klaxa> yes
[22:44] <Adrellias> ahhh
[22:44] <Adrellias> *fp*
[22:44] <Adrellias> sorry
[22:44] <Adrellias> Thank you and sorry for not rtfs
[22:44] <klaxa> heh :P
[22:48] <jned> I don't get how to view the stream once its playing
[22:49] <jned> ffplay http://localhost:8090/feed1.ffm give me error: HTTP error 404 Not Found http://localhost:8090/feed1.ffm: Input/output error
[22:49] <klaxa> can you pastebin your ffserver.conf?
[22:50] <jned> klaxa, I didn't edit it, should be default
[22:50] <jned> 1 sec
[22:52] <jned> klaxa http://pastebin.com/0wqWaVtz
[22:53] <klaxa> you should be able to play http://localhost:8090/test1.mpg
[22:54] <jned> klaxa, thx
[22:55] <jned> so you don't have to write any html with ffmpeg, it streams to internet on its own
[00:00] --- Tue Sep 3 2013
1
0
[00:37] <ubitux> BBB: what about the 64x64 blocks in vp9?
[00:37] <ubitux> BBB: do transforms for those blocks really exist? or they're only "segmentable" in 32x32 and smaller?
[00:38] <libfud> hey all, I don't know how important to you this is, but I'll say it anyway. Statically building ffmpeg against musl instead of glibc fails unless you patch libavutil/error.c to include string.h and use -D_BSD_SOURCE as a CFLAG
[00:38] <libfud> sorry if this isn't the right place to say it
[00:40] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:8349be852be7: avformat/lxfdec: use a parser to parse video frame headers
[00:49] <michaelni_> libfud, can you submit a clean patch that fixes this ?
[00:50] <libfud> michaelni_: sure thing
[00:51] <libfud> I have the patch uploaded already to https://github.com/libfud/sabotage/blob/newpkgs/KEEP/ffmpeg-avutil.patch
[00:51] <libfud> where do I submit it to?
[00:51] <ubitux> libfud: system header on top
[00:51] <libfud> oh
[00:52] <ubitux> also, a patch needs to be against git/HEAD
[00:52] <libfud> ok, I'll write it against that
[00:52] <ubitux> thx
[00:52] <libfud> no problem
[00:52] <libfud> I'm pretty new to this kind of stuff
[00:53] <libfud> so I appreciate being told when I'm doing something fucked up
[00:53] <michaelni_> about submit to: ffmpeg-devel mailing list (https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/)
[00:54] <durandal_1707> libfud: musl?
[00:54] <libfud> so, above #undef _GNU_SOURCE or below that
[00:55] <libfud> durandal_1707: http://www.musl-libc.org/intro.html
[00:56] <durandal_1707> well if you want it get fixed you either: report bug or sent patch or find someone who will do it for you
[01:07] <libfud> I sent an email to the mailing list
[01:20] <iive> libfud: nice to see musl getting more popular
[01:21] Action: pippin also enjoys musl ;)
[01:22] <iive> :O
[01:23] <libfud> yeah
[01:23] <iive> on what platform are you using it?
[01:23] <libfud> I've fallen in love with it, everything builds a hell of a lot faster
[01:24] <libfud> well, I started testing it out on fedora x86, but I'm currently chrooted into sabotage
[01:24] <libfud> which I can boot from but I can't figure out how to get X running properly yet
[01:24] <pippin> iive: I use it on arm
[01:25] <pippin> (kobo ereaders actually)
[01:25] <libfud> heh
[01:26] Action: pippin should probably give hacking up ffplay for the kobo a go; it will probably work at ~10fps but have no sound :p
[01:27] <iive> too bad I have to leave.
[01:28] <iive> libfud: do you mean that musl compiles faster or that gcc compiles everything faster under musl?
[01:29] <libfud> gcc compiles faster when linking against musl than glibc
[01:29] <iive> hehe, sounds grate.
[01:29] <libfud> or so it seems to me, I remember how long building certain packages took with gentoo
[01:29] <libfud> which def. used glibc and not musl
[01:30] <iive> I know the author spent quite some time polishing memory allocations and thread creation.
[01:30] <iive> well, have fun. gtg
[01:30] <libfud> see you later
[01:30] <iive> n8 ppl.
[01:35] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:03882030982c: avformat/utils: fix duration_fields calculation when need_parsing=0
[04:27] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:990bbc15b8e7: avcodec/error_resilience: change out commented printf() to av_log()
[04:27] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:93cf7b01950b: avcodec/h264: set er.ref_count earlier
[10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/1.1:e27fab0e6ee0: avformat/lxfdec: use a parser to parse video frame headers
[10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/1.2:95d0baa95217: avcodec/h264: set er.ref_count earlier
[10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/1.2:458933fdb8d5: avformat/lxfdec: use a parser to parse video frame headers
[10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/2.0:be47e931343e: avcodec/h264: set er.ref_count earlier
[10:10] <cone-108> ffmpeg.git 03Michael Niedermayer 07release/2.0:237ef710a177: avformat/lxfdec: use a parser to parse video frame headers
[10:52] <ubitux> fun, ted hardcode subtitles now for various formats & languages
[10:53] <ubitux> i wonder why they just didn't mux them
[11:40] <cone-108> ffmpeg.git 03Stefano Sabatini 07master:51b01573e536: ffprobe: fix format section XML validation
[11:40] <cone-108> ffmpeg.git 03Stefano Sabatini 07master:291ad12ea2d1: ffprobe: show probe_score in the format section
[12:58] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:d7f917c37af2: fate: update fate tests after master:291ad12ea2d1: ffprobe: show probe_score in the format section
[13:06] <cone-108> ffmpeg.git 03Christian Schmidt 07master:a42e3a670054: pcm_dvd: consolidate pieces from pcm.c and mpeg.c
[13:06] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:cb4d05e7f256: Merge commit 'a42e3a6700547e4e49445bda81d3a89ec3e081a9'
[13:07] <cone-108> ffmpeg.git 03Martin Storsjö 07master:789cd1de99cd: pcm-dvd: Fix build on big endian
[13:07] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:7c1805869d6f: avcodec/pcm-dvd: discard buffer if block size changed
[13:36] <cone-108> ffmpeg.git 03Diego Elio Pettenò 07master:faa8245bd45c: vf_lut: Constantize
[13:36] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:67d7ea9825f6: Merge commit 'faa8245bd45c1a6dd220ba9407ea1c82132aa1ce'
[14:00] <cone-108> ffmpeg.git 03Vittorio Giovara 07master:f4ca970dba13: configure: Add docdir configuration option
[14:00] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:d8809b357c5e: Merge commit 'f4ca970dba13a60a1334cce1b574036e6f624b9c'
[14:14] <cone-108> ffmpeg.git 03Martin Storsjö 07master:21ffd4101167: pcm-dvd: Fix build on big endian
[14:14] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:8901f48e636b: Merge remote-tracking branch 'qatar/master'
[14:54] <compn> what is the status of redcode support?.
[14:54] <compn> and bayer rgb
[14:54] <compn> colorspace
[15:34] <michaelni__> compn, i wanted to work on bayer rgb in ffv1 and maybe sws if noone else does it (peter had worked on that a bit)
[15:34] <compn> yeah, i see peters patch from 2012
[15:36] <compn> maybe ping him?
[15:37] <michaelni> compn, dont hesitate to ... and feel free to cc me
[15:37] <wm4> so, I have a .ts sample that works fine with the vlc and mkvmerge demuxer, but not libavformat or mplayer
[15:38] <wm4> how do I make someone care
[15:38] <compn> upload it
[15:38] <michaelni> compn, i mean if you ping privately, if its on ffmpeg-dev no need to cc :)
[15:39] <wm4> compn: one example (a user uploaded it, sorry for the hoster he picked): https://mega.co.nz/#!zR0wWK4L!B-RGF3sreOsUMyBshBQc8x74iRhtNi7tFt3Wcu74vUE
[15:39] <compn> ok michael, just im on a tablet, in france, so even writing emails is not easy ehe
[15:39] <wm4> works perfectly in vlc
[15:40] <wm4> ffplay craps itself (so does anything mplayer with -demuxer lavf)
[15:40] <wm4> mplayer's -demuxer mpegts appears to work fine, but actually video timestamps are jumping around
[15:41] <wm4> (it basically works only because mplayer is in a mode that ignores video timestamps for most of playback, hurr)
[15:48] <michaelni> compn, no hurry it can wait until you have a real keyboard to type
[15:58] <compn> argh mega's js is so bloated
[16:07] <wm4> compn: it's bloated on purpose
[16:17] <iive> compn: you are in france. congratulation (y)
[17:48] <cone-108> ffmpeg.git 03Peter Ross 07master:9116995efb9c: libavutil: add AV_PIX_FMT_BAYER pixel formats
[17:48] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:4aeb996f71bd: pixfmt: add native bayer 16bit formats
[18:05] <wm4> what are these bayer things?
[18:05] <Daemon404> colorspaces
[18:05] <Daemon404> many cameras use them
[18:05] <wm4> shouldn't this be a raw codec instead of it's so irregular
[18:09] <wm4> "The pixel format descriptors are set to more or less arbitrary values as bayer formats do not fit in the descriptors structure."
[18:09] <wm4> oh the fun
[18:10] <michaelni> the problem with a raw codecs for it is that there are codecs that store bayer and id like to add support to ffv1 for it too
[18:10] <michaelni> s/a//
[18:11] <wm4> if the pixdescs make no sense, maybe they simply shouldn't be set (like with hwaccel formats)
[18:11] <michaelni> yes, they are pretty much set only minimally to get the average bits per pixel correct
[19:06] <nevcairiel> builds fail completely now if texi2html is not present? whats this madness?
[19:07] <wm4> yeah, I've noticed someone else had the same problem, I think
[19:09] <nevcairiel> half of fate is red because of that
[19:09] <wm4> heh
[19:10] <wm4> so it seems the mpc8.c decoder can return 0, which means it wants to packet to be repeated
[19:11] <wm4> a bit odd... is it guaranteed it can't cause the caller to enter and endless decoding loop?
[19:11] <wm4> s/and/an/
[19:13] <nevcairiel> some codecs work like that, they decode subframes separately to lower latency for example, and needs to be called a few times with the same packet
[19:13] <nevcairiel> if thats something mpc8 does, or if its just bugged, i couldnt tell
[19:14] <wm4> normally you'd expect them to return the number of bytes consumed (as it is documented) - but I suppose some codecs need the full packet or so to decode more sub frames or so
[19:16] <nevcairiel> it could also be that it consumes the packet the first call, and then refuses to consume nothing of the next packet until it decoded the first one completely
[20:04] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:91acb23a2880: doc: fix insane hard texi2html dependancy
[21:23] <cone-108> ffmpeg.git 03Paul B Mahol 07master:fc435d977a53: pcm-dvd: remove redundant log message
[21:23] <cone-108> ffmpeg.git 03Paul B Mahol 07master:5be7aecc80b5: pcm-dvd: use av_freep()
[22:08] <durandal_1707> something is making red fate
[22:14] <Daemon404> /bin/sh: texi2html: not found
[22:14] <Daemon404> make: *** [doc/ffmpeg.html] Error 127
[22:14] <Daemon404> someone mae texi2html non-optional
[22:14] <Daemon404> made*
[22:17] <nevcairiel> that should already be fixed again
[22:17] <nevcairiel> my fate boxes passed again
[22:17] <Daemon404> nevcairiel, its a shame you could come to VDD
[22:17] <Daemon404> lots of fun, lots of trolling
[22:18] <Daemon404> couldnt8
[22:18] <Daemon404> *
[22:19] Action: ubitux finds those social events kind of extremely boring at some point though
[22:19] <Daemon404> you werent in many of the interesting rooms
[22:19] <Daemon404> or at least i didnt see you in them
[22:20] <ubitux> the only interesting one was ffmpeg ;)
[22:20] <Daemon404> daala was quite interesting
[22:20] <Daemon404> tim is awesome
[22:20] <ubitux> i was there
[22:20] <Daemon404> i also herped and derped in the x265 room
[22:20] <Daemon404> and spent a bunch of time talking to that youtube guy
[22:20] <ubitux> i was afraid of a huge amount of trolling in x265 so i didn't go there
[22:21] <Daemon404> i took the piss out of the
[22:21] <Daemon404> m
[22:21] <Daemon404> <_<
[22:21] <ubitux> yeah the youtube discussion in ffmpeg room was cool
[22:21] <ubitux> which means 2 hours were enough instead of the week end, at least for me
[22:21] <durandal_1707> how many were in that room?
[22:21] <ubitux> i felt like wasting my time a bit, but that was expected
[22:22] <ubitux> durandal_1707: around 12 iirc
[22:22] <Daemon404> well, i didnt get bored anyway
[22:22] <Daemon404> lots of people to talk to
[22:23] <Daemon404> also i didnt see you at parc asterix
[22:23] <durandal_1707> ubitux: so what it was all about?
[22:23] <durandal_1707> you never saw me
[22:23] <Daemon404> i was talking about ubitux
[22:24] <Daemon404> actually the only one i saw ther was compn, i think
[22:24] <ubitux> durandal_1707: the youtube guy expressed his will to help and raised the main issue they have with ffmpeg
[22:24] <Daemon404> ubitux, he also told me hes sending an edit list patch soon (tm)
[22:24] <durandal_1707> yes... (i'm all ears)
[22:25] <wm4> edit lists?
[22:25] <Daemon404> mp4 edit lists
[22:25] <wm4> ew
[22:25] <ubitux> durandal_1707: which is basically mov/mp4 edit list, captionning, and some colorspaces issues
[22:25] <ubitux> also mpegts bad support forcing them to hf with mencoder
[22:25] <ubitux> and he was asking what youtube could do to help
[22:25] <wm4> haha
[22:26] <wm4> port vlc's ts demuxer?
[22:26] <Daemon404> ubitux, he also wanted to do something with vimeo, like a big regression suite/test using our samples
[22:26] <wm4> and kill the old code with fucking fire
[22:26] <Daemon404> i think kind of like coverity, giving the devs access
[22:26] <Daemon404> or something like that, perhaps separate
[22:27] <ubitux> ah btw, kierank
[22:27] <ubitux> how is the gpu draft? :)
[22:29] <ubitux> <@Daemon404> also i didnt see you at parc asterix // i don't find much things fun tbh, and especially not that kind of activities
[22:29] <Daemon404> heh
[22:30] <kierank> ubitux: opus in TS draft first
[22:30] <ubitux> :(
[22:31] <durandal_1707> gpu draft?
[22:31] <kierank> ubitux: opus in TS is more interesting than GPUs, no?
[22:31] <kierank> durandal_1707: explain to people why GPU encoding is a scam
[22:32] <kierank> And doesn't work
[22:32] <ubitux> kierank: not for me
[22:32] <Daemon404> i can perhaps start a rough point form list
[22:32] <Daemon404> i get enogh BS email about GPUs
[22:32] <Daemon404> but not tonight
[22:32] <wm4> I thought hardware based encoding is normal for consumer cameras and TV stations and such?
[22:34] <ubitux> ow and i almost forgot to watch the eotena ep this w-e with all those adventures!
[22:59] <kierank> wm4: hardware encoding is not the same as gpu
[23:31] <funman> 22:26 <+wm4> port vlc's ts demuxer?
[23:33] <funman> ubitux: do you remember what problem he (Thierry) had with ts ?
[23:33] <ubitux> nope
[23:36] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:c72cca5a44d8: avcodec/ffv1dec: move initial_states init to init_thread_copy()
[23:36] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:21dc3a3cc23c: avcodec/ffv1dec: reorganize thread init/update
[23:37] <wm4> funman: well, there are some samples around
[23:37] <durandal_1707> there are reported bugs
[23:40] <funman> wm4: if you have a link i can test them with vlc, i have a few samples that are not working as well
[23:40] <wm4> funman: a user linked me this today, I think it plays fine in vlc https://mega.co.nz/#!zR0wWK4L!B-RGF3sreOsUMyBshBQc8x74iRhtNi7tFt3Wcu74vUE
[23:41] <wm4> it appears you got completely broken timestamps with libavformat, or something similarly weird
[23:49] <funman> yup, mplayer plays it as well btw
[23:57] <wm4> funman: mplayer doesn't handle it really well, for one, mplayer mostly ignores video timestamps in this case, and you can see the playback time "fluctuating"
[00:00] --- Mon Sep 2 2013
1
0
[00:05] <crBenLubar> I'm trying to encode some pngs and a wav into webm. Here's my command line: http://pastebin.com/xM0dsmaH
[00:05] <crBenLubar> the problem is that the video is coming out in grayscale
[00:10] <durandal_1707> add -vf format=rgb24 ?
[00:11] <durandal_1707> this is bug where pal8 gets converted to gray
[00:11] <crBenLubar> where in the command line should I put that?
[00:11] <durandal_1707> michaelni_: ^
[00:12] <durandal_1707> actually your input png is not pal8 at all
[00:12] <durandal_1707> you sure that pngs are correctly decoded by ffmpeg ?
[00:12] <crBenLubar> well they were encoded by ffmpeg from tga files
[00:13] <crBenLubar> since I wanted to reduce the file size
[00:13] <durandal_1707> well have you look at them?
[00:13] <crBenLubar> and all the png files look fine in gimp
[00:15] <crBenLubar> here's an arbitrary input frame: http://i.imgur.com/qXW7jtq.jpg
[00:15] <crBenLubar> (imgur converted to jpeg, not me)
[00:17] <durandal_1707> well jpeg is uselss for me
[00:21] <crBenLubar> http://rnoadm.net:1337/dump/flawless_victory2500.png
[00:36] <durandal_1707> crBenLubar: what ffmpeg version?
[01:24] <kriskropd> I'm writing a short ffmpeg line that is supposed to rip one frame for every second of video - I thought if I changed switch '-r' to 1 it would do that, but I appear to be wrong - can anybody share guidance with me?
[01:24] <Mavrik> yeah, that doesn't really do that
[01:24] <Mavrik> use select video filter
[01:35] <kriskropd> Mavrik: I looked around the manual and I'm not sure how I should do that
[01:35] <Mavrik> kriskropd, basically, select filter chooses which frames are transcoded
[01:35] <kriskropd> I mean, I don't see an option for that
[01:36] <Mavrik> documentation, filters, select
[01:36] <Mavrik> examples.
[01:36] <Mavrik> example: "select frames with minimum distance of 10 seconds"
[01:37] <kriskropd> thats not in my man page ._.
[01:37] <kriskropd> checking online manual
[01:38] <kriskropd> okay, I think I found it - had to use a search engine to find it though
[01:38] <kriskropd> -vframes 1 out.png
[01:39] <kriskropd> erm -vf fps=fps=1 ?
[01:39] <Mavrik> kriskropd, I was talking about this actually: http://ffmpeg.org/ffmpeg-filters.html#select_002c-aselect
[01:39] <Mavrik> -vf select=<expression>
[01:39] <Mavrik> there are multiple examples there depending on which frames you want
[01:40] <Mavrik> kriskropd, rule of thumb: use online doc instead of man pages ;)
[01:40] <kriskropd> Mavrik: I have a thing of avoiding web browsers :(
[01:46] <kriskropd> okay, this isn't working still, I did '-vf select=1' to get 1 fps
[01:46] <kriskropd> it didn't work but it didn't give any errors either
[01:49] Action: kriskropd scrolls down and finally sees Mavrik
[01:49] Action: kriskropd 's example
[01:50] <kriskropd> that's insane, i wonder why i t has to be so complicated ._. oh well, testing this now
[01:54] <kriskropd> but it seems to have worked so thank you
[04:06] <JodaZ_> can i cut video with ffmpeg in a single invokation ? like just a few seconds here, and a few there and splice it together ?
[09:14] <kriskropd> I have a clip that I used video fade filters with, howeve rI cannot find matching audio fade filters - can anyone help direct me with that? My first idea is to extract audio from the clip I'm rendering and then process with sox and then reattach it to the clip
[09:36] <kriskropd> I'm also having a trouble with fps, when I run 'ffmpeg -r 1 -i input.m2v -r 24 output.avi' I receive 'Option framerate not found.'
[10:32] <mkozjak> hi
[10:32] <mkozjak> is there any way for ffmpeg decode italic tags from srt while burning hardsubs to the video?
[10:37] <ubitux> it should be the case by default
[10:37] <ubitux> -vf subtitles=foo.srt should do that
[10:38] <mkozjak> ok
[10:39] <mkozjak> maybe there's a difference in versions? when was that decoding introduced?
[10:40] <ubitux> it's been a while now
[10:40] <ubitux> maybe 1.1 or 1.2
[10:52] <mkozjak> ok
[14:56] <roger21> hey
[14:57] <roger21> i have a little problem, i transcode a mkv to avi(xvid/mp3) the playback is good but neither mediainfo nor virtualdub see the audio track
[14:57] <roger21> it's a 2pass encode if it help
[14:58] <roger21> so is there some option i can put to make the audio track more visible?
[14:58] <roger21> file see the audio track
[14:59] <roger21> sees
[14:59] <roger21> idk
[15:07] <roger21> is there some verbs that don't change with he/she/it
[15:07] <roger21> ?
[15:07] <roger21> like he cans or he can
[15:08] <roger21> i'm not sure
[15:08] <roger21> so it's can
[15:10] <roger21> are all the codec option relevant at the first pass
[15:10] <roger21> i thought since it is just analysing the source file and such that the encoding option wouldn't matter but the log fil actually changes
[15:14] <roger21> it is also a vbr audio, does it matter ?
[15:19] <roger21> does the -map option would help
[15:20] <roger21> i don't see the point of this option so far
[15:24] <Mavrik> huh.
[16:05] <roger21> Mavrik, http://pastebin.com/TiZVnpyx
[16:11] <relaxed> roger21: it might be because you're using vbr mp3
[16:12] <relaxed> use -r:v 24000/1001 instead of -r:v 23.976
[16:12] <roger21> oh
[16:13] <roger21> will do
[16:39] <roger21> yep, cbr fixed it (kind of sad)
[16:56] <xzise> Hi, I tried to trim my video with ffmpeg, but -ss and -t aren't exact even when I reencode and use them as an output option.
[17:01] <grepper> xzise: probably has to do with key frames, so getting an "exact" frame is difficult
[17:03] <xzise> unfortunately I can't show you an example with the material where it isn't working but and I'm trying to replicate it with other material but it appears to work there
[17:04] <xzise> is it possible to determine the key frames? And when I'm using ffmpeg -i in.mkv -ss 4.2 -c:v libx264 out.mkv my impression was, that this is "exact"
[17:06] <grepper> it seeks to the nearest keyframe
[17:07] <grepper> so you get approximate, depending on your gop size
[17:16] <xzise> O.O hmmm I thought -ss as an input option or when using the copy codec would be inaccurate, but as soon as you reencode the content it should work. Is there a way to cut at exact frames?
[17:17] <Mavrik> xzise, what is your command line?
[17:17] <xzise> ffmpeg -i in.mkv -c:v libx264 -ss 4.2 out.mkv
[17:21] <grepper> transcode (transcoding.org) or a visual video editor like avidemux could make the process easier.
[18:43] <kriskropd> I have a clip that I used video fade filters with, however I cannot find matching audio fade filters - can anyone help direct me with that? My first idea is to extract audio from the clip I'm rendering and then process with sox and then reattach it to the clip
[18:44] <kriskropd> but it seems like libav should just be able to do this somehow
[18:44] <klaxa> http://ffmpeg.org/ffmpeg-filters.html#afade
[18:44] <klaxa> how about that?
[18:49] <kriskropd> klaxa: that looks liek what I want, but I'm getting "Unrecognized option 'afade..."
[19:01] <kriskropd> is there no sort of '-af' option for audio filters?
[19:02] <klaxa> never used audio filters, so dunno actually
[19:14] <kriskropd> I'm having no luck :( either I get "Unrecognized option" or "No such filter: 'afade'"
[19:55] <grepper> if ffmpeg -filters doesn't show it, maybe yours is too old
[19:56] <grepper> $ ffmpeg -filters 2>&1 |grep afade
[19:56] <grepper> afade A->A Fade in/out input audio.
[20:05] <kriskropd> I'm using : ffmpeg version 0.8.6-6:0.8.6-1ubuntu2, Copyright (c) 2000-2013 the Libav developers
[20:06] <kriskropd> from ubuntu repos
[20:10] <klaxa> then you are using avconv and not ffmpeg
[20:13] <kriskropd> I'm not sure waht the differences are, afterall I get the same errors with both (I've been trying everything with both commands
[20:21] <kriskropd> mkay, so f*** avconv cause the documentation sucks - I need something, anything at this point, that does what it says it does :x
[20:21] <kriskropd> if latest ffmpeg works with afade, then I'll go compile
[20:26] <grepper> kriskropd: or you could try a static build if you are lazy :)
[20:35] <kriskropd> thanks for the links and the help - I'll have to read up and get back to this later it seems
[20:41] <grepper> its just a single binary, download it and try it :)
[21:09] <kriskropd> grepper: I did, I had to go back through documentation to see what the actually correct form might most likely be. turns out -af afade... worked :)
[21:42] <kriskropd> this one is just for fun, but I was wanting to toy with stereo3d when I saw in in the docs, but I don't have any left&right framed videos - I tried using alternating frames to make fun motion blur like stereo 3d effect, but I wonder if ffmpeg has a way to jitter the images (maybe like smartbrtblur?) and use those for the left and right images per frame
[21:43] <kriskropd> smartblur*
[21:44] <durandal_1707> stereo3d doesn't do any motion blur
[21:47] <kriskropd> durandal_1707: I'm aware of that, but I used alternating frames on a monoscopic video, which pretty much overlayed frames to create the stereoscopic effect - it was "like" motion blurringring
[21:48] <kriskropd> now I'm wondering if I can have ffmpeg render frames to use for both left and right while it processes a monoscopic video - either via displacement or formulated blurring
[00:00] --- Mon Sep 2 2013
1
0
[00:53] <BBB> michaelni: so if you look at emulated_edge_mc, it takes a single stride argument and assumes that the image and emu buffer hold the same stride. what if the image is 1 mb by 1 mb (16x16 in mpeg, for example) and the MV is subpel, so we need a 17x17 temp buffer? the stride is only 16 so this wouldn't work
[00:54] <BBB> (if -flags +emu_edge is set)
[00:54] <BBB> michaelni: so ... does emulated_edge_mc need 2 stride arguments?
[00:54] <BBB> this affects codecs other than mpeg also ofc - in fact this affects all codecs equally
[01:05] <michaelni> BBB, hmm, stride =16 isnt supported atm, even with 2 stride emu , at least some of the MC code itself also assume src_stride == dst_stride if iam not mistaken
[01:05] <michaelni> and the MC code couldnt read 17x17 with a stride=16 source
[01:06] <BBB> it's an issue for vp9 (and potentially hevc) where the base block unit is larger
[01:06] <BBB> I mean, nobody sane would make a 16x16 video
[01:06] <BBB> but a 64x64 video...
[01:06] <BBB> I mean, that's how realnetworks got big
[01:06] <BBB> I can just say it's unsupported but it doesn't feel quite right, I'm not 100% sure about it
[01:07] <michaelni> iam not against adding a 2nd stride parameter to emu
[01:07] <michaelni> the alternative would be maybe to enforce a larger stride and copy that 64x64 image to 64 stride
[01:08] <michaelni> but if a 2nd stride for emu is all thats needed then thats probably simpler
[01:08] <BBB> depends on the codec
[01:08] <BBB> mc needs 2 stride arguments
[01:08] <michaelni> otoh if all MC asm needs to be changed ...
[01:08] <BBB> and emulated_edge_mc needs 2 stride arguments
[01:08] <BBB> right
[01:08] <BBB> :)
[01:08] <BBB> I'm not looking forward to that
[01:09] <BBB> for a corner case that nobody ever uses...
[01:10] <BBB> vp8 mc asm has 2 stride arguments
[01:10] <BBB> so it's not unprecedented
[01:11] <BBB> I was thinking of whether to use 1 or 2 stride arguments for vp9 mc functions
[01:11] <BBB> I just changed it all to 1 to be consistent with h264 etc
[01:11] <BBB> but now thinking of going back to 2
[01:11] <BBB> not sure yet what's best
[01:11] <michaelni> well, i dont know either what is best. You work on the code you are in a better position to decide that
[01:12] <BBB> probably for future codecs 2 stride arguments is better, since a 64x64 block size and a 64x64 image just isn't completely unfeasible
[01:12] <BBB> whereas 16x16 just won't ever happen
[01:12] <BBB> I mean, nobody makes 16x16 videos
[01:15] <michaelni> the internet is big, theres probably little that wont ever happen, luckly we dont have to support every insane thing someone creates
[03:16] <cone-84> ffmpeg.git 03Michael Niedermayer 07master:227a0eb5a924: avformat/avidec: match first index and first packet size=0 handling
[04:54] <cone-84> ffmpeg.git 03Michael Niedermayer 07release/1.1:890c36d7ff1a: avcodec/ffv1dec: check global header version
[04:54] <cone-84> ffmpeg.git 03Michael Niedermayer 07release/1.1:df2fc635439d: ffv1dec: check that global parameters dont change in version 0/1
[04:54] <cone-84> ffmpeg.git 03Michael Niedermayer 07release/1.1:f78a3868fd3d: ffv1dec: Check bits_per_raw_sample and colorspace for equality in ver 0/1 headers
[04:54] <cone-84> ffmpeg.git 03Michael Niedermayer 07release/1.1:558d0b9483d0: avcodec/dsputil: fix signedness in sizeof() comparissions
[05:37] <cone-84> ffmpeg.git 03Michael Niedermayer 07release/1.1:86bf0a8871df: update for 1.1.6
[05:58] <cone-84> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.1.6': unknown revision or path not in the working tree.
[05:58] <cone-84> Use '--' to separate paths from revisions
[05:58] <cone-84> refs/tags/n1.1.6:HEAD: avformat/avidec: match first index and first packet size=0 handling
[09:48] <cone-345> ffmpeg.git 03Michael Niedermayer 07release/0.10:49f434ce2e5e: avformat/avidec: match first index and first packet size=0 handling
[09:48] <cone-345> ffmpeg.git 03Michael Niedermayer 07release/0.11:d3ef17740d93: avformat/avidec: match first index and first packet size=0 handling
[09:48] <cone-345> ffmpeg.git 03Michael Niedermayer 07release/0.9:cf701b008fd3: avformat/avidec: match first index and first packet size=0 handling
[09:48] <cone-345> ffmpeg.git 03Michael Niedermayer 07release/1.0:6b5c4be9e0b5: avformat/avidec: match first index and first packet size=0 handling
[09:48] <cone-345> ffmpeg.git 03Michael Niedermayer 07release/1.1:f743c4ece8a8: avformat/avidec: match first index and first packet size=0 handling
[09:48] <cone-345> ffmpeg.git 03Michael Niedermayer 07release/1.2:32cff0d3f096: avformat/avidec: match first index and first packet size=0 handling
[09:48] <cone-345> ffmpeg.git 03Michael Niedermayer 07release/2.0:1821c849da5b: avformat/avidec: match first index and first packet size=0 handling
[10:54] <compn> yo from vdd
[10:55] <ubitux> ah you there?
[10:55] <compn> yes
[10:55] <compn> saw michael time out, whered he go?
[10:56] <ubitux> not at vdd i believe
[11:01] <compn> i know that
[11:03] <compn> kostya is here
[11:05] <compn> hi carl on irc log
[11:06] <compn> i met merbanan and wbs. not sure about daemon...
[11:07] <Daemon404> yes you did
[11:08] <compn> ok, then i did
[11:08] <compn> hehe
[11:10] <compn> oh michael is on irc im blind
[11:10] <JEEBsv> :)
[11:10] <compn> hollywood studios will never let dcp without drm....
[11:11] <compn> they'd rather lose the entire country revenue than let that happen
[11:44] <ubitux> compn: so where are you now?
[12:24] <compn> in the conf
[12:24] <compn> in a theatre with a bunch of devs
[12:25] <compn> insulting speakers, j-b just insulted mplayers edl
[12:25] <ubitux> i know im here
[12:25] <compn> oh lol , im near the top.
[12:25] <ubitux> and i laught, sry ;)
[12:26] <compn> where you at ubi? raise your hand
[12:26] <ubitux> we are half way, dtarting left
[12:26] <ubitux> no i wont raise my hand ;)
[12:26] <compn> haha ok
[12:26] <compn> vp9!
[12:27] <kierank> ubitux: compn is the guy with the huge beard
[12:29] <compn> i have my beard tucked, its hiding...
[12:32] <compn> beastd said it was only him and me from mplayer
[12:32] <compn> have to update him..
[13:46] <cone-497> ffmpeg.git 03Christian Schmidt 07master:0d6549d8b57a: pcm_bluray: rename pcm-mpeg.c to pcm-bluray.c
[13:46] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:4273236e2f63: Merge commit '0d6549d8b57aaa5be8efb794154cdbe9a645910f'
[13:54] <cone-497> ffmpeg.git 03Christian Schmidt 07master:21fd2f84ce21: pcm_bluray: cosmetics
[13:54] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:b043d80be4d8: Merge remote-tracking branch 'qatar/master'
[14:11] <cone-497> ffmpeg.git 03Carl Eugen Hoyos 07master:e7da19e9fa45: Fix make checkheaders for vdpau_internal.h
[14:11] <cone-497> ffmpeg.git 03Carl Eugen Hoyos 07master:b970f85564ba: Fix make checkheaders for wavpackenc.h
[14:11] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:4fa00c567cd5: Merge remote-tracking branch 'cehoyos/master'
[14:15] <ubitux> i would like to say thank you free for providing some spaces for vdd
[14:15] <ubitux> but i would also like to say fuck you free for my fucking home connection
[14:15] <ubitux> isp my ass ffs
[14:17] <Daemon404> http://www.speedtest.net/my-result/2935767733
[15:33] <ubitux> what do you want to tell me compn ?
[15:33] <compn> do you want to spend 1 year on a genric edl or apply mp4 patch and seperate mkv patch?
[15:33] <ubitux> nope
[15:33] <ubitux> :)
[15:34] <compn> its multiple choice
[15:34] <compn> not yes no
[15:34] <ubitux> none"
[15:34] <ubitux> "none"
[15:34] <compn> none of those?]
[15:35] <compn> whats the alt?
[15:35] <ubitux> none of everything
[15:35] <ubitux> i suggest to wait for jesus
[15:35] <compn> is baptiste going to merge ffmbc?
[15:36] <compn> with ffmpeg i mean
[15:40] <mateo`> compn: that would be great :)
[21:13] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:336982a0ce15: avcodec/utils: avcodec_string: make the colorspace printing code more extendible.
[21:13] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:ea07dbdeaa66: avcodec/utils: avcodec_string: Print color_range
[21:13] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:8da23be458f4: avcodec/utils: avcodec_string: print colorspace type
[00:00] --- Sun Sep 1 2013
1
0
[12:19] <XAVeRY> hey there. I got a very weird mpg file that produces such output when passed to ffmpeg -i : http://codepad.org/1UvbxBAe .
[12:19] <XAVeRY> mplayer plays this file okay, so it is playable, but I'm looking for ways to fixup the header or whatever's wrong with this file. any clues?
[12:19] <XAVeRY> thanks in advance.
[12:26] <Mavrik> XAVeRY, hmm
[12:26] <Mavrik> you could try remuxing, but that looks like a badly broken stream
[12:26] <XAVeRY> Mavrik, I did - things seem a bit better now.
[12:26] <Mavrik> just do ffmpeg -i <file> -codec:copy outfile.ts
[12:27] <XAVeRY> remuxed it to mkv, we'll see how it goes.
[12:27] <XAVeRY> Mavrik, I'm most concerned about the errors from the h264 decoder. hopefully, it won't be that much trouble.
[12:28] <Mavrik> you could probably get rid of those with remuxing to a global-header container (e.g. mp4)
[12:28] <Mavrik> those aren't that critical as long as the PPS/SPS packets are at least partially there
[12:36] <compn> xavery, can you paste mplayer output?
[12:37] <XAVeRY> compn, just normal output when I'm playing?
[12:37] <compn> yes
[12:38] <compn> on that file
[12:38] <XAVeRY> compn, http://codepad.org/BMVV6BgK
[12:42] <compn> hmmmmmmmmm
[12:42] <compn> stumping me
[12:42] <compn> you compiled mplayer?
[12:42] <compn> against ffmpeg?
[12:42] <XAVeRY> compn, no, it's an Arch Linux package. but I can compile it if you want.
[12:42] <compn> it could be libav mplayer?
[12:43] <compn> you compiled ffmpeg or binary?
[12:43] <XAVeRY> compn, no, it was binary.
[12:43] <compn> hmmmmm
[12:44] <compn> well, id say try git, might be fixed
[12:45] <compn> otherwise im out of ideas and it maybe real bug
[12:45] <XAVeRY> compn, I doubt that. I'd really suspect the stream to be actually borked in a way.
[12:45] <XAVeRY> I recorded it on Windows, via a very shabby application that came with my tuner
[12:46] <compn> ok, well if it works in mplayer
[12:46] <compn> you can use mencoder or mplayer to convert it
[12:47] <compn> depending what codec you want
[12:48] <compn> or if you just want to try remuxing
[12:48] <compn> there is tsmuxer or mkvmerge might be able to fix it
[12:49] <XAVeRY> compn, thanks a lot for the advice. :) I'll see what I can do with those.
[12:49] <compn> ok, i might not be here later, but stick around and some one can help
[12:50] <compn> if you upload your file, we can test with git too...
[12:50] <XAVeRY> well, remuxing to mkv seems to have worked.
[12:50] <compn> great
[12:50] <XAVeRY> thanks a lot, Mavrik & compn.
[12:50] <compn> np
[13:53] <XAVeRY> I had some sync issues after muxing the streams together, but fixed it with mkvmerge.
[13:53] <XAVeRY> thanks again, compn & Mavrik.
[14:44] <Neil_> Hello people. I'm trying to convert a video that is 1920x1080 but i get an error saying to increase MAX_FILTER_SIZE - where would I find this and what should I set it to?
[14:53] <Neil_> if anyone could tell me which file it's in? I tried '/ffmpeg_sources/ffmpeg/configure' - where else to look?
[14:53] <Mavrik> uhm
[14:53] <Mavrik> can you give your full console output in a pastebin?
[14:57] <Neil_> here you go : http://pastebin.com/ydLgVpT1
[14:58] <Neil_> the command line I'm trying to use is: ffmpeg -i "$1" -vcodec libx264 -vprofile high -preset slow -b:v 850k -maxrate 850k -bufsize 1000k -vf scale=1:720 -threads - -acodec copy "${1%%sm.*}.mp4"
[14:59] <Neil_> I just want the video to be 720 adn not 1920 as it's messing things up
[15:02] <Mavrik> Neil_, em, the bug.
[15:02] <Mavrik> "-vf scale=-1:720"
[15:02] <Mavrik> 1:720 is the part that freaks sws_scale out :)
[15:05] <Neil_> ok, so what did I do wrong? I looked at a couple of website 'HOWTO's' and thought that was the right way to change resolution
[15:05] <Neil_> Arrrgh - I missed the minus sign out!
[15:06] <Mavrik> yep :)
[15:12] <Neil_> Mmm - so now I have ffmpeg -i "$1" -vcodec libx264 -vprofile high -preset slow -b:v 850k -maxrate 850k -bufsize 1000k -vf scale=-1:720 -threads - -acodec copy "${1%%sm.*}.mp4" but I get this as an error:
[15:12] <Neil_> http://pastebin.com/zi7CQv7i
[15:12] <Neil_> just shoot me...
[15:12] <Mavrik> Neil_, um
[15:12] <Neil_> -threads - -a... Not my day :-(
[15:12] <Mavrik> it says clearly
[15:13] <Mavrik> your threads parameter is wierd :P
[15:22] <Neil_> thank you!
[19:29] <vad> ffmpeg 2.0.1 seems to have a very weird behavior in that it keeps encoded frames in memory rather than writing them out until very late..
[19:30] <vad> The status output is then quite ridiculous: frame=15371 fps= 37 q=2.0 size= 440kB time=00:10:41.28 bitrate= 5.6kbits/s
[19:36] <klaxa> i have noticed that too
[19:36] <microchip_> vad: open a ticket, then
[19:44] <vad> I can't help but procrastinate :)
[19:45] <Mavrik> vad, which muxer?
[19:45] <vad> mkv container, using -c:v mpeg4
[19:46] <Mavrik> huh.
[19:46] <Mavrik> why.
[19:49] <vad> I have a gut feeling it may be caused by the input file o_O
[20:13] <burek> can anyone tell me what is this thing: http://pastebin.com/AFX8s7U9
[20:13] <burek> vlc also can't play it
[20:14] <durandal_1707> use mplayer with drivers
[20:15] <durandal_1707> actually that is DRM
[20:16] <durandal_1707> if you did not paid for it you can not watch it
[20:16] <burek> f it, i'll re-download a better copy anyway :)
[20:17] <burek> i don't know who pays for movies in these days :)
[20:17] <durandal_1707> it looks encryption is done in container(asf) and not in video bitstream
[20:17] <durandal_1707> it woult be nice if you could watch it if you have key
[20:18] <durandal_1707> but to have key, you need to pay....
[20:19] <burek> they can bite me :)
[20:19] <burek> btw, there is some info in metadata
[20:20] <klaxa> well it's 640x480 anyway
[20:21] <durandal_1707> some pr0n
[20:21] <klaxa> also wmv and wma? wut
[20:21] <klaxa> why would you want that stuff
[20:21] <durandal_1707> he is pirate
[20:21] <klaxa> especially then he should have higher standards by now
[20:24] <durandal_1707> i do not they are so dumb to store key in metadata
[20:24] <durandal_1707> s/they/think they/
[20:25] <burek> it was a torrent download, i just wanted to watch a movie that's all no biggie
[20:26] <durandal_1707> there is probably brute force to break drm but i not going to do it for free....
[20:26] <burek> i didn't even see it was 640x480
[20:26] <burek> no need to, there are free tools for that anyway :) http://stream-recorder.com/forum/four-ways-remove-drm-wmv-and-wma-t9592.htm…
[20:26] <durandal_1707> burek: you waste bandwitch on fake torrents
[20:26] <burek> but i'll download hd copy
[20:26] <burek> wasn't watching carefuly at descr :D
[20:28] <vad> to err is human, but to really screw up requires a computer
[20:33] <burek> :)
[00:00] --- Sun Sep 1 2013
1
0