[00:01] <ubitux> yeah i was wondering about the version bump
[00:02] <ubitux> also i don't think in this case the bump matters really
[00:02] <ubitux> since it's likely to be a bug of forgotten header
[00:02] <ubitux> more than adding a new prototypes
[00:02] <ubitux> nore sure of the impact of not bumping though
[00:02] <ubitux> i guess we can also wait for the 0.11 release :)
[00:04] <ubitux> saste: btw, i think you forgot to add tools/ffeval in the .gitignore
[00:05] <saste> ubitux: uhm ok... feel free to do that for me, i'm a bit brainscattered you know
[00:07] <CIA-63> ffmpeg: 03Clément BSsch 07master * r35894ebbf9 10ffmpeg/.gitignore: Add tools/ffeval to .gitignore.
[00:09] <ubitux> saste: btw, you seemed to be a bit in a hurry to proceed to SPI in your mail, so don't see my questions as blocking, i was just curious :)
[00:11] <_tibo_> hi, I'm using FFmpeg for Android compiled with Neon support. I play h.264 video, and I'm wondering if the function sws_scale is optimized for Neon ?
[00:13] <michaelni> _tibo_, do you know NEON and want to optimize code?
[00:15] <ubitux> anyway, 'night ppl
[00:15] <_tibo_> michealni: I'm only asking if it's optimized in some way because, for comparison purpose, I'm using a Neon optimize lib to do the conversion, and I got the same CPU load than using sws_scale...
[00:15] <michaelni> n8 ubitux
[00:19] <michaelni> theres no neon code in there currently, i dont remember for sure if someone wrote some but refused to release it
[00:20] <michaelni> that said, are you sure you dont want to write some neon optims :) ?
[00:20] <michaelni> it would really make many people happy ..
[00:23] <_tibo_> michaelni: ok thx. I'm not a neon export... I just happen to use that for an android project. But I found some assembly code made by ARM, so it can maybe reused for FFmpeg
[00:26] <michaelni> depends on license compatibility and what the code does. I suspect it may be not so easy though
[00:26] <michaelni> but a patch that adds any neon support is definitly welcome (in case its license is LGPL compatible) and it has been tested
[01:19] <PapaSmurf007> kierank: can you clarify your statement about having different types for macroblocks in the same frame, "yes, in a p/b frame" meaning you can have an MB forward predicted and an MB bidirectionally predicted in the same frame?
[02:33] <CIA-63> ffmpeg: 03Alex Converse 07master * r3607dc2b1a 10ffmpeg/doc/avconv.texi: doc: Replace a stray reference to the old '-intra' flag.
[02:33] <CIA-63> ffmpeg: 03Luca Barbato 07master * r5699884c2e 10ffmpeg/ (4 files in 2 dirs):
[02:33] <CIA-63> ffmpeg: sctp: Initial tcp-alike sctp support with streams
[02:33] <CIA-63> ffmpeg: Signed-off-by: Jordi Ortiz <nenjordi at gmail.com>
[02:33] <CIA-63> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[02:33] <CIA-63> ffmpeg: 03Jordi Ortiz 07master * r38f06a1415 10ffmpeg/libavcodec/libschroedingerdec.c:
[02:33] <CIA-63> ffmpeg: libschroedingerdec: Change AVPicture to AVFrame and use SchroTag to store pts
[02:33] <CIA-63> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[02:33] <CIA-63> ffmpeg: 03Jordi Ortiz 07master * rfcd0298c05 10ffmpeg/libavformat/ (rtsp.c rtsp.h):
[02:33] <CIA-63> ffmpeg: rtsp: Add content-type message header parsing
[02:33] <CIA-63> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[02:33] <CIA-63> ffmpeg: 03Alex Converse 07master * r40f81769ae 10ffmpeg/ (libavcodec/options_table.h libavformat/options_table.h):
[02:33] <CIA-63> ffmpeg: options_table: Add some missing #includes to fix "make checkheaders".
[02:33] <CIA-63> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[02:33] <CIA-63> ffmpeg: 03Mans Rullgard 07master * r6766169c41 10ffmpeg/libavutil/mips/intreadwrite.h:
[02:33] <CIA-63> ffmpeg: mips: intreadwrite: fix inline asm for gcc 4.8
[02:33] <CIA-63> ffmpeg: Just like gcc 4.6 and later on ARM, gcc 4.8 on MIPS generates
[02:33] <CIA-63> ffmpeg: inefficient code when a known-unaligned location is used as a
[02:33] <CIA-63> ffmpeg: memory input operand. This applies the same fix as has been
[02:33] <CIA-63> ffmpeg: previously done to the ARM version of the code.
[02:33] <CIA-63> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:33] <CIA-63> ffmpeg: 03Anton Khirnov 07master * rac71230902 10ffmpeg/ (10 files in 3 dirs):
[02:33] <CIA-63> ffmpeg: lavfi: add video buffer sink, and use it in avtools
[02:33] <CIA-63> ffmpeg: Also add the public interface libavfilter/buffersink.h.
[02:33] <CIA-63> ffmpeg: Based on a commit by Stefano Sabatini.
[02:33] <CIA-63> ffmpeg: 03Diego Biurrun 07master * rf2a5586c64 10ffmpeg/tests/ (17 files in 2 dirs):
[02:33] <CIA-63> ffmpeg: fate: split some combined tests into separate audio and video tests
[02:33] <CIA-63> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:33] <CIA-63> ffmpeg: 03Anton Khirnov 07master * rab165047a6 10ffmpeg/libavfilter/ (avfilter.c avfilter.h):
[02:33] <CIA-63> ffmpeg: dealing with more than 8 channels.
[02:33] <CIA-63> ffmpeg: 03Anton Khirnov 07master * r0982b0a431 10ffmpeg/libavresample/ (avresample.h utils.c version.h): lavr: make avresample_read() with NULL output discard samples.
[02:34] <CIA-63> ffmpeg: 03Anton Khirnov 07master * r6d7f617700 10ffmpeg/libavutil/ (samplefmt.c samplefmt.h): samplefmt: add a function for filling a buffer with silence.
[02:34] <CIA-63> ffmpeg: 03Diego Biurrun 07master * r5b432d66ce 10ffmpeg/libavcodec/ (Makefile libxvid_rc.c libxvidff.c):
[02:34] <CIA-63> ffmpeg: libxvid: Separate libxvid encoder from libxvid rate control code.
[02:34] <CIA-63> ffmpeg: This allows compiling the Xvid rate control code without the encoder.
[02:34] <CIA-63> ffmpeg: 03Mans Rullgard 07master * rb1f9be5436 10ffmpeg/tests/ (4 files in 2 dirs):
[02:34] <CIA-63> ffmpeg: fate: split idroq audio and video into separate tests
[02:34] <CIA-63> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:34] <CIA-63> ffmpeg: 03Diego Biurrun 07master * r727af82a84 10ffmpeg/libavcodec/jpeglsdec.c:
[02:34] <CIA-63> ffmpeg: jpeglsdec: Remove write-only variable in ff_jpegls_decode_lse().
[02:34] <CIA-63> ffmpeg: libavcodec/jpeglsdec.c:54:9: warning: variable len set but not used
[02:34] <CIA-63> ffmpeg: 03Anton Khirnov 07master * r142e740d1e 10ffmpeg/libavutil/ (samplefmt.c samplefmt.h): samplefmt: add a function for copying audio samples.
[02:34] <CIA-63> ffmpeg: 03Stefano Sabatini 07master * r1b8c9271bd 10ffmpeg/libavfilter/ (avfilter.c avfilter.h):
[02:34] <CIA-63> ffmpeg: lavfi: add avfilter_get_audio_buffer_ref_from_arrays().
[02:34] <CIA-63> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[02:34] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r7610dee87b 10ffmpeg/libavfilter/avfiltergraph.c:
[02:34] <CIA-63> ffmpeg: avfiltergraph: improve pick_format()
[02:34] <CIA-63> ffmpeg: without this the recent changes to format/sink handling would cause a regression in fate
[02:34] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:34] <CIA-63> ffmpeg: 03Anton Khirnov 07master * ra5117a2444 10ffmpeg/ (6 files in 3 dirs): lavc: pad last audio frame with silence when needed.
[02:34] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r61930bd0d7 10ffmpeg/: (log message trimmed)
[02:34] <CIA-63> ffmpeg: Merge remote-tracking branch 'qatar/master'
[02:34] <CIA-63> ffmpeg: * qatar/master: (27 commits)
[02:35] <CIA-63> ffmpeg: libxvid: Give more suitable names to libxvid-related files.
[02:35] <CIA-63> ffmpeg: libxvid: Separate libxvid encoder from libxvid rate control code.
[02:35] <CIA-63> (4 lines omitted)
[04:19] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * reee89f691e 10ffmpeg/ (libavformat/cdg.c tests/ref/fate/cdgraphics):
[04:19] <CIA-63> ffmpeg: cdg: fix pts
[04:19] <CIA-63> ffmpeg: Fixes Ticket1226
[04:19] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[12:15] <mrmuhhh> hi!
[12:17] <mrmuhhh> maybe somone could help me here :) iam currently trying to encode frames from my opengl app (rgb frames) into a mpeg4 or h264 video
[12:23] <mrmuhhh> is there an another example than the mpeg1 sample from here http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/api-example_8c-source.html
[12:55] <ubitux> mrmuhhh: yes, http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples;hb=HEAD
[13:04] <Compn> j-b : invite people to paris, travel expenses paid, and all you get in return are bikesheds about the abbreviated name of the event :D
[13:04] <Compn> hehe
[13:06] <av500> Veneral Disease Days
[13:06] <av500> what else to get in paris...
[13:06] <mrmuhhh> ubitux ok this looks very promising thx! it seems to work great with mpeg1, but switching to h264 generates some x264 output but the file isnt "playable"
[13:07] <ubitux> you need some kind of container i guess
[13:08] <ubitux> arh libav keeping the exact same function name than in ffmpeg
[13:08] <ubitux> seriously&
[13:08] <ubitux> (and changing the prototype)
[13:08] <ubitux> that sucks quite hard
[13:08] <mrmuhhh> aaahhh
[13:09] <mrmuhhh> the exension was the problem :) thx !!
[13:10] <mrmuhhh> i assume that h264 requires yuv as input or is rgb also possible ?
[13:28] <Compn> mrmuhhh : h264 is yuv only iirc. i could be wrong
[13:28] <Compn> check pix_fmt list in h264dec.c or h264enc probably :P
[13:28] <Compn> ubitux : abi breakage is just first step in fork rules. it gets worse
[13:29] <ubitux> life is sad :(
[13:32] <av500> it's called fork for a reason, not branch
[13:33] Action: ubitux prefers spooning development methods
[14:12] <burek> could I just point out here, instead of creating a bug report in trac, that ffmpeg should handle -af in some way, either by throwing an error/warning or mapping to lavfi
[14:12] <burek> this way, if ffmpeg just silently ignores -af, users will just think it's a bug or something
[14:18] <j-b> Compn: as expected :)
[14:22] <mrmuhhh> thx Compn for the hint!
[14:54] <mrmuhhh> greats works perfect now with rgb -> yuv (swscale) and encoding with x264 :) thx to all!
[14:57] <mrmuhhh> *great,
[15:19] <mrmuhhh> hm is ffmpeg capable to write/create a container? the video_encode_example only generates the "raw" video stream or?
[15:30] <Compn> mrmuhhh : libavformat is the one that writes the container
[15:30] <Compn> libavcodec does the codecs
[15:30] <Compn> swscale does the swscale :)
[15:35] <mrmuhhh> and is it possible to use the output of the video_encode_example directly to write into a mp4 / mkv etc. ?
[15:35] <mrmuhhh> like in the muxing example ... http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/muxing.c;h=9d338dee670699d07b1f87505d78ee52a17cb920;hb=HEAD
[15:38] <Compn> no clue
[15:38] <Compn> try libav-users mailing list if you are creating software with libavcodec but not actual ffmpeg :)
[15:39] <mrmuhhh> hehe ok good idea :=
[18:18] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r91e72e3514 10ffmpeg/libavformat/omadec.c:
[18:18] <CIA-63> ffmpeg: omadec: Check geob datasize more completely
[18:18] <CIA-63> ffmpeg: Fixes out of heap array read.
[18:18] <CIA-63> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[18:18] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:18] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r8ea5df4fac 10ffmpeg/libavcodec/utils.c:
[18:18] <CIA-63> ffmpeg: lavc/utils: fix division by 0
[18:18] <CIA-63> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[18:18] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:23] <Daemon404> ubitux, are you familiar with vf_select, or should i wait for saste?
[18:33] <ubitux> no i'm not really
[18:35] <Daemon404> damn
[18:35] <Daemon404> k
[18:35] <Daemon404> im trying to figure out how to make it seek to the nearest keyframe
[18:35] <Daemon404> when selecting its range
[18:35] <Daemon404> (so only cut at kf)
[18:35] <ubitux> there is pict_type for this iirc
[18:36] <Daemon404> that doesnt seem exactly liek what i want
[18:36] <Daemon404> # select only I-frames
[18:36] <Daemon404> select='eq(pict_type\,I)'
[18:36] <Daemon404> ^ only example
[18:37] <Compn> Daemon404 did you see michaelni's request for you to try to get libav api matched up w/ ffmpeg ?
[18:38] Action: Daemon404 would rather not be involved in :politics: D:
[18:38] <Compn> well its not politics, just abi talk
[18:38] <Compn> but ok, i wont harass you
[18:38] <Daemon404> no, it's politics.
[18:38] <Daemon404> it's always politics.
[18:38] <Compn> lol
[18:38] <ubitux> Daemon404: i think the eval system allows you to store variable
[18:39] <ubitux> you might be able to set that variable to 1 when eq(pict_type,I)
[18:39] <Daemon404> ubitux, i have NO idea how the eval system works
[18:39] <Daemon404> especially not how to upll this off
[18:39] <Daemon404> docs arent helping
[18:39] <ubitux> @item st(var, expr)
[18:39] <ubitux> should be this
[18:40] <Daemon404> im not really sure how that helps.
[18:40] <ubitux> eval.texi is lacking some examples mmh
[18:41] <ubitux> Daemon404: well you could do [VAR1]*eq(pict_type\,I), assuming [VAR1
[18:41] <ubitux> [VAR1] is set to 1 if one pict type already occured
[18:41] <ubitux> (i'm using "[VAR1]" but that's not the syntax)
[18:41] <Daemon404> pict_type
[18:41] <Daemon404> is nto documented.
[18:42] <ubitux> (certainly a ld() is necessary)
[18:42] <Daemon404> well
[18:42] <ubitux> Daemon404: pict_type is a select specific value
[18:42] <Daemon404> basically
[18:42] <ubitux> it is replaced into eval
[18:42] <Daemon404> this shit is so poorly documented i cant figure out how the heck to use it.
[18:42] <Daemon404> without readign src
[18:42] <ubitux> Daemon404: i'm going to try to figure out something
[18:43] <Daemon404> filter docs and eval docs have consistently been lacking in clarity for me...
[18:43] Action: Daemon404 shrugs
[18:43] <ubitux> maybe something like st(1, eq(pict_type\,I) * ld(1)); ld(1)
[18:44] <Daemon404> my goal is
[18:44] <ubitux> mmh maybe + instead of *
[18:44] <Daemon404> given 2 timestamps
[18:44] <Daemon404> e.g. 30secodns and 40seconds
[18:44] <Daemon404> seek to nearest iframes and use that range
[18:44] <Daemon404> for both
[18:44] <Daemon404> this is turning out to be very nontrivial.
[18:45] <ubitux> i'd say something like st(1, eq(pict_type\,I) + ld(1)); ld(1) * gt(t, 30) * lt(t, 40)
[18:45] <ubitux> (but that's most likely not correct)
[18:46] <ubitux> i'm attempting to set register 1 with the value 1 if the current frame is an intra (or if already set to one)
[18:46] <Daemon404> alsthat doesnt look right
[18:46] <Daemon404> -als
[18:46] <ubitux> and then use that result with the timestamp range
[18:46] <ubitux> that's just a guess
[18:46] <ubitux> i never used eval() intensively
[18:46] <ubitux> but that's an interesting problem
[18:47] <ubitux> i'm willing to add such example if we are able to achieve something :)
[18:47] <Daemon404> i would think it is a common use case
[18:49] <Daemon404> (and this needs to be frame-accurate, it's for splitting, and then rejoining a video)
[18:49] <ubitux> sure
[18:50] <ubitux> st(1,eq(pict_type\,I)+ld(1)); gte(t\,30)*lte(t\,40)*ld(1)
[18:50] <ubitux> does this work?
[18:51] <Daemon404> i dont get how that makes sense
[18:51] <Daemon404> :|
[18:51] <ubitux> (i just hope ld(1) without previous store will work)
[18:51] <ubitux> ok let me re-explain what i'm trying to do
[18:51] <Daemon404> how would that ensure 30s and 40s are kf?
[18:51] <ubitux> *ld(1)
[18:51] <ubitux> ld(1) means load variable/register 1
[18:52] <ubitux> which was loaded with the value: eq(pict_type\,I)+ld(1)
[18:52] <ubitux> which means var1 = var1 || kf
[18:52] <ubitux> at least that's what i'm trying to do
[18:52] <ubitux> gte(t\,30)*lte(t\,40)*ld(1) this needs the 3 conditions have to me
[18:52] <ubitux> t>=30 AND t<=40 AND var1
[18:53] <Daemon404> wouldnt that drop all non-kf inside the range?
[18:53] <ubitux> ld(1) will be 1 if one keyframe was expected
[18:53] <ubitux> (ah and we need to add the gte(t\,30) in the load condition)
[18:54] <ubitux> oh there is a while()
[18:54] <Daemon404> what i think would be useful is simplt to have a gt/gte that are keyframe-aware
[18:55] <Daemon404> the reason im trying to use keyframes, is becayse of the whole frame-accuracy thing
[18:55] <ubitux> a nice way would be to set a constant with the kf state
[18:55] <Daemon404> id gladly just use 30s and 40s, for example
[18:56] <Daemon404> but i cant guarantee this works so i can join later
[18:56] <Daemon404> and select cant take frame #s afaik
[18:57] <ubitux> you can specify the frame id with select if that's what you mean
[18:57] <Daemon404> wtf is a frame id?
[18:57] <ubitux> frame number i mean
[18:57] <ubitux> (n and selected_n)
[18:57] <Daemon404> i dont see
[18:57] <Daemon404> i only see pts stuff
[18:57] <ubitux> first constant
[18:58] <Daemon404> ah i see
[18:58] <Daemon404> now teh big question: can i actually rely on cutting using n
[18:58] <Daemon404> and joining late
[18:59] <ubitux> n is computed with a counter
[18:59] <ubitux> not based on timestamp or anything
[18:59] <ubitux> so i guess it's safe
[19:02] <Daemon404> too bad ffprobe doesnt show duration in frames
[19:02] <Daemon404> kind of makes it a pita
[19:02] <ubitux> ?
[19:02] <ubitux> there is a count_frames option
[19:02] <Daemon404> oh
[19:03] <Daemon404> btw
[19:03] <ubitux> also, showinfo filter might help
[19:03] <Daemon404> whoever thought json output was a good idea fo ffprobe
[19:03] <Daemon404> i thank ye
[19:03] <ubitux> :)
[19:03] <ubitux> np ;)
[19:03] <Daemon404> was that you?
[19:04] <ubitux> yeah
[19:04] <Daemon404> nice
[19:04] <Daemon404> we're finally gonna ditch mediainfo for ffprobe
[19:04] <ubitux> i was looking for making my own youtube-like
[19:04] <Daemon404> supposedly, using json
[19:04] <ubitux> and i needed a export-info-easy
[19:05] <ubitux> it made saste going crazy and improving the "writer" system in ffprobe way better
[19:05] <ubitux> to support xml, compact view etc
[19:05] <ubitux> he did a great work on this :)
[19:05] <Daemon404> :P
[19:06] <ubitux> btw, showinfo filter shows frame numbers
[19:06] <Daemon404> yes but i want a total duration
[19:07] <Daemon404> so i can split into N parts
[19:07] <ubitux> ah, then count frames
[19:07] <Daemon404> that seems to be extremely slow
[19:07] <ubitux> yes
[19:07] <Daemon404> when i can just Duration: 01:04:55.82, start: 0.000000, bitrate: 10935 kb/s
[19:07] <Daemon404> ^ parse this
[19:07] <ubitux> you might avoid the decode
[19:07] <ubitux> try with demuxing only
[19:08] <ubitux> also, there is a frame number "estimate" iirc (it might be extracted from the container or sth)
[19:08] <Daemon404> it isnt immediately clear to me how to do this
[19:08] <ubitux> with packets instead of frames
[19:08] <Daemon404> it only needs to be rough
[19:08] <Daemon404> since the last segment is just N until end
[19:10] <ubitux> nb_frames should be displayed by default if the stream exports it
[19:11] <ubitux> nb_read_frames demux+decode+count
[19:11] <ubitux> nb_read_packets demux+count
[19:11] <ubitux> (and with video 1 packet should be 1 frame)
[19:13] <Daemon404> yeah but that requires custom code
[19:14] <Daemon404> i hoped to avoid htis
[19:14] <ubitux> what requires custom code?
[19:14] <ubitux> nb_frames and then fallback to nb_read_packets?
[19:14] <Daemon404> yes?
[19:14] <ubitux> ok
[19:14] <Daemon404> it would require me to use the api directly, wouldnt it?
[19:15] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r7c7c5b2415 10ffmpeg/libavutil/log.c:
[19:15] <CIA-63> ffmpeg: avutil/log: allow av_log_set_callback (NULL)
[19:15] <CIA-63> ffmpeg: Idea-by: Don Moir <donmoir at comcast.net>
[19:15] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:15] <ubitux> Daemon404: i was talking about the displayed key by ffprobe
[19:16] <Daemon404> ?
[19:16] <ubitux> i think we have a misunderstanding& :D
[19:16] <Daemon404> maybe we do
[19:16] <Daemon404> i certainly dont see this info
[19:16] <Daemon404> (im not using json atm)
[19:16] <Daemon404> is it only exported then?
[19:17] <ubitux> - ./ffprobe -show_streams -print_format json ~/samples/big_buck_bunny_1080p_h264.mov|&grep nb_frames "nb_frames": "14315", "nb_frames": "1", "nb_frames": "27960",
[19:17] <Daemon404> i was usaing default print_format
[19:17] <Daemon404> i -figured- the info between formats would not differ
[19:17] <Daemon404> >_>
[19:17] <ubitux> ah sorry
[19:17] <ubitux> nb_frames=14315
[19:17] <ubitux> nb_frames=1
[19:17] <ubitux> nb_frames=27960
[19:17] <ubitux> works with the default too
[19:18] <ubitux> but there is a slight difference with some writers
[19:18] <ubitux> when the value is not available, some writers don't display them
[19:18] <ubitux> while other print N/A or something
[19:18] <ubitux> (but that's customizable iirc)
[19:18] <Daemon404> huh
[19:18] <Daemon404> {
[19:18] <Daemon404> }
[19:18] <Daemon404> ^ entire json output
[19:19] <ubitux> you need to requests what you want to print
[19:19] <ubitux> formats, streams, ...
[19:19] <ubitux> -show_streams
[19:19] <ubitux> -show_formats
[19:19] <ubitux> -show_packets
[19:19] <ubitux> etc :)
[19:20] <Daemon404> indeed
[19:20] <Daemon404> tho
[19:20] <Daemon404> those are very sparsely documented in -help
[19:20] <Daemon404> two words lol
[19:20] <ubitux> doc/ffprobe.texi
[19:20] <ubitux> http://ffmpeg.org/ffprobe.html#Writers
[19:21] <ubitux> http://ffmpeg.org/ffprobe.html#Main-options
[19:22] <Daemon404> i meant it doesnt really document what sort of info each outputs
[19:22] <Daemon404> theyre still very vague.
[19:23] <Daemon404> or what each thing liek nb_read_frames is
[19:24] <ubitux> this option will only appears with specific options
[19:24] <ubitux> that is if you explicitely request a count
[19:24] <ubitux> i agree the documentation is lacking such information
[19:24] <ubitux> but i think it's more appropriate to an overview page or something
[19:25] <ubitux> documenting every fields ffprobe can display would be too much
[19:25] <Daemon404> yet it's pretty critical :P
[19:26] <ubitux> just curious, is this for your work at vimeo?
[19:26] <Daemon404> yea
[19:26] <ubitux> ok :)
[19:26] <ubitux> sounds fun
[19:26] <Daemon404> indeed
[19:31] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * rafcb67113d 10ffmpeg/ (configure libavcodec/allcodecs.c libavcodec/libvorbis.c): (log message trimmed)
[19:31] <CIA-63> ffmpeg: Revert "Remove libvorbis Vorbis decoding support. Our native decoder is complete"
[19:31] <CIA-63> ffmpeg: Its useful to support the official decoder for comparission and debugging.
[19:31] <CIA-63> ffmpeg: This reverts commit f9def9ccc6ecfe1778d4daa62a7ada27b5f79bfc.
[19:31] <CIA-63> ffmpeg: Conflicts:
[19:31] <CIA-63> ffmpeg: Changelog
[19:31] <CIA-63> ffmpeg: configure
[20:08] <tg2> how much work would it be to add an -sframe equivalent to -ss that starts on specified frame
[20:08] <tg2> instead of specified time
[20:10] <michaelni> tg2, if you dont care about speed, its easy
[20:11] <tg2> why is that?
[20:11] <tg2> i can /probably/ do it by checking framerate and time
[20:11] <nevcairiel> count frames from the beginning, win :)
[20:12] <tg2> how would you go about splitting a video into 8 parts and encoding them separately
[20:12] <JEEB> tg2, use timestamps (DTS) of frames, not frame rate
[20:12] <JEEB> because frame rate can be variable
[20:12] <tg2> hmm
[20:12] <tg2> so do it by time
[20:13] <tg2> is what you're saying :)
[20:13] <JEEB> no
[20:13] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r36ab79488e 10ffmpeg/ffmpeg.c:
[20:13] <CIA-63> ffmpeg: ffmpeg: fix uninitialized variable warning
[20:13] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:13] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r0ee32b9028 10ffmpeg/ffmpeg.c:
[20:13] <CIA-63> ffmpeg: ffmpeg: remove unused variables
[20:13] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:13] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * rb7fe9c7a08 10ffmpeg/ffmpeg.c:
[20:13] <CIA-63> ffmpeg: ffmpeg: fix pointer type (const) warning
[20:13] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:13] <tg2> explain pls
[20:13] <JEEB> what I'm saying that if you're going to use frame rate, rather use DTS
[20:13] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r648dbae519 10ffmpeg/libavfilter/vf_idet.c:
[20:13] <CIA-63> ffmpeg: vf_idet: fix pointer type (const) warning
[20:13] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:13] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r2a793ff2bf 10ffmpeg/libavfilter/vf_lut.c:
[20:13] <CIA-63> ffmpeg: vf_lut: fix pointer type (const) warning
[20:13] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:13] <CIA-63> ffmpeg: 03Michael Niedermayer 07master * r98e409ecaa 10ffmpeg/libavfilter/vf_idet.c:
[20:13] <tg2> ah ok
[20:13] <tg2> is there a command line call to ffmpeg that will give total frames and total duration
[20:14] <CIA-63> ffmpeg: vf_idet: remove unused variables
[20:14] <CIA-63> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:14] <tg2> ffmpeg-php seems to have it in $movie->getFrameCount()
[20:28] <Daemon404> ubitux, ugh
[20:28] <Daemon404> select us USELESS
[20:28] <Daemon404> it doesnt seek
[20:28] <Daemon404> -_-
[20:28] <Daemon404> is*
[20:28] <Daemon404> it just decoces everything linearly until it gets there
[20:29] <nevcairiel> could a filter even seek...?
[20:29] <Daemon404> a man can dream...
[20:30] <Daemon404> nevcairiel, so whats a non-windows solution to avs's trim? :P
[20:30] <nevcairiel> i dunno, i'm a windows person
[20:48] <Compn> whats avs trim do ?
[20:51] <michaelni> if someone wants to add seeking support to av filters, that should be pretty easy
[20:51] <michaelni> just pass a seek command backward ...
[20:55] <Daemon404> trim(30,40) will get you [30,40]
[21:03] <michaelni> should be easy to implement simply passing a expression in a string backward and let the source perform seek/drop/eof based on its evaluation
[21:04] <michaelni> pts>=X && dts<Z && chapter==V
[21:04] <Daemon404> michaelni, i have no idea how to do that ;) (i stay away from that stuff)
[21:05] <Compn> what happens when you seek with a filter currently ?
[21:05] <Daemon404> you dont.
[21:05] <Compn> does mplayer have ff filters yet ?
[21:05] <Compn> oh
[23:33] <CIA-63> ffmpeg: 03Stefano Sabatini 07master * re727bca392 10ffmpeg/libavfilter/ (avfilter.c avfilter.h defaults.c): (log message trimmed)
[23:33] <CIA-63> ffmpeg: lavfi: cleanup avfilter_get_audio_buffer() and pals.
[23:33] <CIA-63> ffmpeg: Remove AVFilterBufferRefAudioProps.size, and use nb_samples in its place
[23:33] <CIA-63> ffmpeg: everywhere.
[23:33] <CIA-63> ffmpeg: This is required as the size in the audio buffer may be aligned, so it
[23:33] <CIA-63> ffmpeg: may not contain a well defined number of samples.
[23:33] <CIA-63> ffmpeg: Also remove the useless planar parameter, which can be deduced from the
[23:33] <CIA-63> ffmpeg: 03Stefano Sabatini 07master * r6735534f19 10ffmpeg/libavfilter/defaults.c: lavfi: use avfilter_get_audio_buffer_ref_from_arrays() in avfilter_default_get_audio_buffer
[23:33] <CIA-63> ffmpeg: 03Stefano Sabatini 07master * r7ef0adcc2e 10ffmpeg/libavfilter/ (avfilter.c avfilter.h defaults.c): (log message trimmed)
[23:33] <CIA-63> ffmpeg: lavfi: simplify signature for avfilter_get_audio_buffer() and friends
[23:33] <CIA-63> ffmpeg: The additional parameters are just complicating the function interface.
[23:33] <CIA-63> ffmpeg: Assume that a requested samples buffer will *always* have the format
[23:33] <CIA-63> ffmpeg: specified in the requested link.
[23:33] <CIA-63> ffmpeg: This breaks audio filtering API and ABI in theory, but since it's
[23:33] <CIA-63> ffmpeg: unusable right now this shouldn't be a problem.
[23:33] <CIA-63> ffmpeg: 03Anton Khirnov 07master * ra6bdfc2a92 10ffmpeg/libavfilter/avfilter.h:
[23:33] <CIA-63> ffmpeg: lavfi: change AVFilterBufferRefAudioProps.sample_rate from uint32_t to int
[23:33] <CIA-63> ffmpeg: There's no reason for it to be explicitly 32 bits. It's declared as a
[23:33] <CIA-63> ffmpeg: plain int in all other places in Libav.
[23:33] <CIA-63> ffmpeg: This breaks audio filtering API and ABI in theory, but since it's
[23:33] <CIA-63> ffmpeg: unusable right now this shouldn't be a problem.
[23:33] <CIA-63> ffmpeg: 03Anton Khirnov 07master * rf20ab492ac 10ffmpeg/libavfilter/ (avfilter.h version.h):
[23:33] <CIA-63> ffmpeg: lavfi: change AVFilterLink.sample_rate from int64_t to int on next bump
[23:33] <CIA-63> ffmpeg: There is no real reason for it to be 64bit, it's just a plain int in the
[23:33] <CIA-63> ffmpeg: rest of Libav.
[23:33] <CIA-63> ffmpeg: 03Anton Khirnov 07master * r472fb3bbfa 10ffmpeg/libavfilter/ (af_anull.c audio.h avfilter.c avfilter.h defaults.c):
[23:33] <CIA-63> ffmpeg: lavfi: remove some audio-related function from public API.
[23:33] <CIA-63> ffmpeg: Those functions are only useful inside filters. It is better to not
[23:34] <CIA-63> ffmpeg: support user filters until the API is more stable.
[23:34] <CIA-63> (64 lines omitted)
[00:00] --- Fri May 11 2012