[Ffmpeg-devel-irc] ffmpeg-devel.log.20150213

[burek]

[00:11] <cone-118> ffmpeg.git 03Gilles Chanteperdrix 07master:afb0e5a810ae: avformat/rtsp: allow receiving subtitles via RTP
[00:38] <cone-118> ffmpeg.git 03Gilles Chanteperdrix 07master:af940e6cb121: avformat/rtpdec: add T.140 RTP depacketization (RFC 4103)
[00:59] <cone-118> ffmpeg.git 03Gilles Chanteperdrix 07master:c7ad1f562b0f: avformat/rtsp: parse lang attribute in SDP
[01:23] <pmarques> hi everyone, I'm using ffprobe to parse metatags but it don't let me catch multiple genres or multiple artists
[01:24] <pmarques> anyone know if there is some thoughts about support it or if it should be supported at all?
[04:32] <cone-201> ffmpeg.git 03Michael Niedermayer 07master:849ad5175b79: avformat/mov: Heuristically detect raw udta
[10:23] <cone-366> ffmpeg.git 03Paul B Mahol 07master:8bb489fab54a: fate: add wavpack encoder
[12:30] <cone-366> ffmpeg.git 03Anton Khirnov 07master:faa8ffda2c51: doc/APIchanges: fill in missing dates and hashes
[12:30] <cone-366> ffmpeg.git 03Michael Niedermayer 07master:c74b3983f99a: Merge commit 'faa8ffda2c513573733624784f0a7d0a4959d33e'
[13:04] <cone-366> ffmpeg.git 03Peter Meerwald 07master:eea769df322f: hevc: Use generic av_clip function, not C implementation
[13:04] <cone-366> ffmpeg.git 03Michael Niedermayer 07master:3e2714992b50: Merge commit 'eea769df322fac2601a96db195fa7dc8d12a8fbc'
[14:02] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:b39ac9d210df: avcodec/vc1: simplify find_next_marker()
[14:49] <ahmed2>  hello , I'm new to the codecs thing , and I search alot before asking but still confused , Can anyone explaine what ffmpeg is ? in a simple words I can understand ? 
[14:51] <ubitux> ahmed2: http://ffmpeg.org/ffmpeg.html#Description http://ffmpeg.org/ffmpeg.html#Detailed-description
[14:57] <compn> ahmed2 : ffmpeg can convert videos from one format to another
[14:58] <bryno> ... and A LOT more!
[14:59] <compn> yep
[15:00] <ahmed2> when I convert a video using handbrak ... what I'm actully using ? x264 or ffmpeg ?
[15:01] <compn> both
[15:01] <iive> ffmpeg is universal video processing program. It consists of libraries that can read and write most file formats (de/muxing), almost complete collection of decoders (including some obscure old video game ones), a have a number of encoders.
[15:01] <iive> x264 is H.264 encoder, and good one at that. ffmpeg can use it externally.
[15:01] <ahmed2> which program is the one who encode videos ? 
[15:01] <iive> or rather, use it as library.
[15:02] <arwa> ubitux,  Can you help me with the fft-domain filtering code? I tried doing a very basic thing, I am just taking fft of rows of the image and idft of it. The code is giving me seg fault. 
[15:02] <arwa> http://pastebin.com/UET2v3DN
[15:02] <iive> a video file consists of audio and video, synchronized to match. x264 can do only video encoding, it doesn't even provide a decoder.
[15:03] <ahmed2> so it's like : ffmpeg is gui for x264 ............ and handbrake is gui for ffmpeg
[15:03] <ahmed2> ?
[15:04] <iive> ffmpeg is definitely not gui.
[15:05] <ahmed2> a command-line front end for x264 and other codecs ?
[15:05] <ahmed2> <iive>
[15:06] <iive> in case you didn't get it. ffmpeg contains its own set of decoders for everything.
[15:07] <iive> it also have huge set of (de)muxers, allowing to read and write different file formats.
[15:07] <BtbN> The ffmpeg cli tool is also just another application using the libav* libraries, which are the primary part of ffmpeg as a project.
[15:07] <iive> it even contains support for different input methods (captures).
[15:13] <ahmed2> this may sound stupid ... But can I use x264  instead of using ffmpeg ? because x264 is the best codec to encode videos into h264 format  
[15:14] <iive> ahmed2: x264 can use libav* libraries from ffmpeg/libav
[15:14] <iive> otherwise you'd need to feed it raw frames and get video without sound.
[15:16] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:b4b9a64bdb61: avcodec/vc1: simplify vc1_split()
[15:23] <ubitux> arwa: where does it segfault? use valgrind or gdb
[15:32] <wm4> michaelni: someone captured mpv's dvb output, which libavformat reportedly crunched on for 5-8 seconds (with default settings); I don't know if the ts is entirely valid: http://srsfckn.biz/mpv-samples/dvb-s2-capture.ts
[15:34] <nevcairiel> on normal file playback, you really dont notice the delays, its only on livestreams because you dont have all the data available, so it waits for it
[15:36] <wm4> and on tvheadend it reportedly needs only 1-2 seconds
[15:36] <nevcairiel> i have some hacks in my code that try to determine if its a streaming  source, and then reduces analyzeduration to 1 second
[15:37] <nevcairiel> it would be ideal if it just stopped after having a pmt and all the streams in it
[15:41] <wm4> and with analyzeduration set to 1 second it still takes 5 seconds
[15:43] <arwa> i tried using valgrind, but it is not showing the line number. :/
[15:45] <arwa> http://pastebin.com/G1mKB35R
[15:45] <arwa> ubitux, ^
[15:46] <mateo`> arwa: maybe use ffmpeg_g instead of ffmpeg
[15:47] <arwa> same error!
[15:47] <arwa> btw what is the diff between ffmpeg and ffmpeg_g?
[15:47] <ramiro> arwa: ffmpeg_g contains debug symbols
[15:47] <ramiro> so that your backtrace actually contains names instead of ??? all over the place =)
[15:48] <arwa> oh nice!
[15:48] <compn> yeah those ??? are not helpful ;D
[15:50] <arwa> yeah...its not helping :/
[15:50] <arwa> it is just showing that the error occured in filter_frame..!
[15:51] <durandal_1707> which filter?
[15:51] <ramiro> pastebin the new error
[15:55] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:e4ea84e12e3a: avcodec/wmv2: simplify cbp_table_index calculation
[15:58] <arwa> fft filter
[15:59] <arwa> http://pastebin.com/Vwaz21PN
[16:00] <arwa> new error ^
[16:00] <ubitux> so what's line 72?
[16:20] <eric_> Hello all! Is there a reason that avformat_free_context -> ff_free_stream does not free the intra_matrix, inter_matrix & rc_override fields? Where as avcodec_free_context does free these fields
[16:21] <wm4> eric_: did you use the AVCodecContext from the AVStream for decoding?
[16:22] <eric_> No, I'm debugging an encoding problem and was just stepping through and noticed this
[16:22] <wm4> or for encoding
[16:22] <wm4> in both cases, the AVCodecContext must be separate AFAIK
[16:24] <eric_> avformat_new_stream creates a new context, which i use
[16:24] <wm4> well, don't
[16:25] <eric_> I saw the note about that in the V11 release notes, but thought using the avformat_new_stream one was ok now
[16:25] <wm4> use avcodec_alloc_context3 and avcodec_copy_context
[16:25] <wm4> (as far as I understood this)
[16:26] <eric_> Yes - I'll change that now
[16:26] <eric_> thanks!
[16:26] <wm4> eric_: try running ffmpeg (the command line program), and see if it has the same leak
[16:27] <eric_> I've not Valgrinded it yet, I just saw it doing a code read
[16:29] <eric_> It seems it might be safer for ff_free_stream to call avcodec_free_context to reduce the code duplication
[16:36] <Daemon404> nevcairiel, Unknown OS 'mingw64_nt-6.3'.
[16:36] <Daemon404> did we ever decide on the 'fix'?
[16:37] <nevcairiel> i guess just extend the mingw32 checks to cover mingw64 as well
[16:37] <nevcairiel> and screw the MSYS* case
[16:37] <Daemon404> nobody should be using that case
[16:37] <Daemon404> i think
[16:38] <nevcairiel> I just hate that its the default if you just call bash.exe
[16:38] <nevcairiel> which a bunch of my scripts do
[16:39] <Daemon404> like x264? ;)
[16:41] <kierank> wm4: ts looks fine
[16:42] <wm4> eric_: that's probably true... though the Libav development direction goes towards removing the AVCodecContext from AVStream entirely
[16:42] <wm4> kierank: nice, so it's really just libavformat, probably
[16:42] <ramiro> last time I tried msys2 it was considerably slower than msys.
[16:43] <ramiro> why do the ffmpeg docs suggest using msys2?
[16:43] <wm4> because msys is dead and broken or something
[16:43] <ramiro> dead - ok, broken - really?
[16:44] <wm4> unless it's 100% bug-free (which is not possible), yes
[16:45] <ramiro> true, but I'd like to know what is so broken about that msys that it's not suitable for building ffmpeg
[16:45] <wm4> oh, ffmpeg probably supports irt
[16:46] <wm4> because ffmpeg supports anything no matter how broken or ancient it is
[16:49] <ramiro> not true, BeOS is gone
[16:50] <durandal_1707> michaelni: the piz bug is on any big endian not just mips?
[16:50] <michaelni> could be, i only tested mips
[17:08] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07fatal: ambiguous argument 'refs/tags/n2.5.4': unknown revision or path not in the working tree.
[17:08] <cone-366> Use '--' to separate paths from revisions
[17:08] <cone-366> refs/tags/n2.5.4:HEAD: avcodec/wmv2: simplify cbp_table_index calculation
[17:19] <durandal_1707> saste: why you removed lavfi from GSoC page?
[17:35] <saste> durandal_1707, because I'm not going to mentor it
[17:46] <Daemon404> now i remember why i dont use the official mingw-w64 toolchains...
[17:46] <Daemon404> fricking winpthreads
[17:47] <ramiro> what's wrong with them?
[17:47] <nevcairiel> winpthreads is broken as fuck
[17:49] <ramiro> more specifically... ?
[17:50] <wm4> I'm interested in this too
[17:51] <nevcairiel> i never bothered to investigate too deep, all I know is that it was slow and deadlocked occasionally
[17:51] <nevcairiel> pthreads-w32 ftw
[17:51] <nevcairiel> although i use w32threads for ffmpeg anyway
[17:52] <ramiro> isn't winpthreads based on pthreads-w32?
[17:52] <nevcairiel> dont think so
[17:52] <nevcairiel> and even if i'm wrong, then they broke it :P
[17:57] <ramiro> hm, apparently it isn't based on pthreads-w32...
[17:58] <ramiro> anyways, nevcairiel, I'm sure kai tietz will be very helpful if you ever encounter a bug and report it to him
[17:58] <nevcairiel> i just dont use it
[18:23] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:bc0a440e889a: avcodec/wmalosslessdec: change type of acfilter_coeffs from int64_t to int16_t
[18:35] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:80f13780051f: avcodec/wmalosslessdec: optimize sign operation
[19:13] <aetasx> I dont have a problem too often with winpthreads but I have been known to bitch about it in the past
[19:29] <wm4> this downstream list looks really useful
[19:29] <wm4> michaelni: keep in mind that if you EOL some ffmpeg releases, the distros using it will probably update
[19:54] <wm4> why does the h264 decoder print "Detected unsupported YCgCo colorspace."
[19:54] <Daemon404> because it detected the colorspace is ycgco
[19:54] <Daemon404> why else?
[19:55] <wm4> why would it care? it exports the flag just fine
[19:55] <Daemon404> i dont know
[19:55] <wm4> of course libswscale barfs all over this, but the decoder should be fine
[19:55] <Daemon404> does swscale support it?
[19:55] <wm4> no
[19:55] <Daemon404> yeah so it's just normal inbreeding
[19:55] <Daemon404> ;)
[19:55] <wm4> trollol
[20:44] <cone-366> ffmpeg.git 03Luca Barbato 07release/2.4:891de4b27a07: log: Unbreak no-tty support on 256color terminals
[20:44] <cone-366> ffmpeg.git 03Xiaohan Wang 07release/2.4:532c96a2158c: matroskadec: Fix read-after-free in matroska_read_seek()
[20:44] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:9d1e775b8966: Merge commit '891de4b27a07b808839b9e873b6a886248c8fd6b' into release/2.4
[20:44] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:92595faab9f4: Merge commit '532c96a2158c04f265d750d54f2f103b8d9fe0ef' into release/2.4
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:0a878d0c941c: doc/APIchanges: Fill in some more missing hash values
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:2029acb6679b: doc/APIchanges: Add av_find_best_pix_fmt_of_2() and av_get_pix_fmt_loss()
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:5080ab26d304: doc/APIchanges: fill in and correct some values
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:05a8114c7190: doc/APIchanges: fill in more missing hash values and dates
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:01b5e61845b8: avformat/utils: Fix number suffixes in tb_unreliable()
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:1ecce1c6a752: swresample/dither: Cleanup number suffixes
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:096fd2698ae9: avcodec/dxtory: Use LL instead of L number suffix
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:1497f355c7ea: avformat/matroskadec: Fix number suffixes
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:84e5b314f354: avformat/smacker: Fix number suffix
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:b8546aee8431: avformat/omadec: fix number suffix
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:8a16b27de9c3: avcodec/h264_cabac: use int instead of long for mbb_xy
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:a31fdcef55e4: avcodec/mpegvideo_enc: Fix number suffixes in rc_buffer_size calculation
[21:00] <cone-366> ffmpeg.git 03wm4 07release/2.4:e2e835f017d6: avformat/tta: fix crash with corrupted files
[21:00] <cone-366> ffmpeg.git 03wm4 07release/2.4:2515de3b1534: avformat/mpc8: fix hang with fuzzed file
[21:00] <cone-366> ffmpeg.git 03wm4 07release/2.4:600c6ebc7d04: avformat/mpc8: fix broken pointer math
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:ee8e48d38677: avformat/mpc8: Use uint64_t in *_get_v() to avoid undefined behavior
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:3531ff8db319: avcodec/mjpegdec: Check escape sequence validity
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:08822122987f: avcodec/mjpegdec: Check number of components for JPEG-LS
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:8413ddcd39ee: avcodec/mpegvideo_motion: Fix gmc chroma dimensions
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:076b98c9b74c: swscale/utils: Limit filter shifting so as not to read from prior the array
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:0c125519ecc4: avformat/thp: Check av_get_packet() for failure not only for partial output
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:3e46e3a33c84: avcodec/h264_ps: More completely check the bit depths
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:724c79276ab2: avcodec/h264: Be more strict on rejecting pps_id changes
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:9dc8f4482985: avcodec/h264: Be more strict on rejecting pps/sps changes
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:1cc419eae8a1: avutil/opt: Fix types used to access AV_OPT_TYPE_PIXEL_FMT
[21:00] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:b250375e77a5: avutil/opt: Fix type used to access AV_OPT_TYPE_SAMPLE_FMT
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:7b213e88b5e6: avcodec/h264_slice: Do not change frame_num after the first slice
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:2073ab266eef: avcodec/h264_slice: Check picture structure before setting the related fields
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:4d5beea7a182: avcodec/h264_slice: ignore SAR changes in slices after the first
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:6005f375aab6: avcodec/h264_slice: assert that reinit does not occur after the first slice
[21:01] <cone-366> ffmpeg.git 03Carl Eugen Hoyos 07release/2.4:ca98c016cd44: lavc/aarch64: Do not use the neon horizontal chroma loop filter for H.264 4:2:2. (cherry picked from commit 4faea46bd906b3897018736208123aa36c3f45d5)
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:492818d724d9: avcodec/mjpegdec: Skip blocks which are outside the visible area
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:1a263f0dd96a: avcodec/arm/videodsp_armv5te: Fix linking failure with "g++ -shared -D__STDC_CONSTANT_MACROS -o test.so ... libavcodec.a"
[21:01] <cone-366> ffmpeg.git 03wm4 07release/2.4:d705125b949b: qpeg: avoid pointless invalid memcpy()
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:43924a8e992f: avcodec/hevc: Fix handling of skipped_bytes() reallocation failures
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:416501da1aa7: avdevice: Use av_format_get_control_message_cb()
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:74c7273b5d5c: avfilter/vf_framepack: Check and update frame_rate
[21:01] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:cb7d72ed1814: avcodec/flac_parser: fix handling EOF if no headers are found
[21:29] <cone-366> ffmpeg.git 03Michael Niedermayer 07release/2.4:d66d5d61881f: Update for 2.4.7
[22:52] <rcombs> http://puu.sh/fSvgp/7b906ed651.png is this evil enough?
[22:56] <ubitux> why not use ffprobe -of json?
[22:57] <wm4> too easy
[22:57] <Loriker> :o)
[22:58] <rcombs> this involves an unhealthy quantity of C++ templates and large macros
[22:59] <wm4> v8?
[22:59] <rcombs> yup
[23:00] <ubitux> all of this makes me very sad
[23:00] <wm4> I'm wondering how hard it'd be to make a V8 vapoursynth wrapper
[23:00] <rcombs> because that AVFormatContext isn't just a bunch of properties of the C struct copied into JS
[23:00] <rcombs> the v8 objects are actually mapped directly to the underlying structs
[23:01] <rcombs> writing to the metadata objects in JS calls av_dict_set
[23:01] <wm4> exactly what we'd need for vapoursynth
[23:01] <wm4> how hard was it?
[23:02] <rcombs> the I/O functions are async and take place on a separate thread and call the callback when they finish
[23:02] <wm4> wat
[23:02] <rcombs> can't be blocking the main event loop :3
[23:03] <wm4> fucking node garbage
[23:03] <rcombs> (callback is called with Null if everything went well and an Exception, whose text comes from av_err2str)
[23:04] <rcombs> wm4: most of the hard parts had to do with finding good docs on v8, because if you google for v8 names you'll generally find Doxygen HTML from before an apparently-recent API overhaul
[23:05] <wm4> so v8 has a sufficiently unstable api
[23:05] <rcombs> I ended up just looking at the headers most of the time
[23:05] <rcombs> oh, and it's not super well-tested, but as far as I'm aware it all GCs well
[23:06] <wm4> maybe I'll give it a try
[23:06] <wm4> hopefully won't end in blowing my brains out
[23:07] <wm4> (a possibility with C++, templates, and google software)
[23:07] <rcombs> the parent objects all keep references to their children, and their children get messages via weak references if their parents are deleted and stop accessing memory that belongs to them
[23:07] <rcombs> (which effectively looks like becoming an empty object)
[23:08] <rcombs> I started from https://github.com/OptimalBits/navcodec and ended up stripping out almost everything
[23:09] <rcombs> because it was largely written badly, with the old v8 API, with what appears to be a poor understanding of both Node module conventions and lav*
[23:09] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:9e6198f0a457: avcodec/wmalosslessdec: simplify
[23:09] <wm4> not sure if I'd write it as node module though
[23:09] <wm4> or will js hipsters hate me if I do not
[23:09] <rcombs> at some point I need to add some JS wrappers that make the functions more friendly and optionally return Promises instead of taking callbacks
[23:12] <rcombs> (right now you see those empty args being passed because if I don't my code throws an exception yelling at me for not having proper args)
[23:12] <rcombs> (because juggling args is not a fun thing to do with the v8 API)
[23:13] <rcombs> (so I just went "fuck it, I'm enforcing everything as being correct and I can wrap it for prettiness in JS later")
[23:14] <wm4> promises sound like a perfect abstraction for the vs frame callback
[23:15] <rcombs> in my experience the best thing about promises is that they make it easy to avoid The Callback Pyramid Of Doom
[23:16] <rcombs> by still having The Callback Pyramid Of Doom but abstracting it so you don't actually have to indent for each one
[23:16] <wm4> meh
[23:16] <wm4> why do badly designed things always get popular
[23:17] <wm4> ok enough hating on node for a day; good night
[23:17] <rcombs> doThing().then(function(ret){&return Promise(things);}).then(&).then(&)
[23:18] <wm4> lol when will thry introduce monads
[23:18] <rcombs> instead of doThing(function(ret){&moreThings(function(stuff){stillMoreThings(function(items){&})})})
[23:18] <rcombs> anything that ends in )})}) is not fun
[23:20] <rcombs> I actually had this whole setup doing everything I wanted it to do hours ago
[23:20] <rcombs> but then decided I should be a bit more thorough about cleaning up the existing code
[23:21] <rcombs> now I'm at the point where I think I'll wipe out everything I haven't gone over (and don't currently need) and push it
[23:24] <cone-366> ffmpeg.git 03zhaoxiu.zeng 07master:0073c8e34500: avcodec/apedec: move 'coeffs[256] and delay[256]' into, long_filter_high_3800
[00:00] --- Sat Feb 14 2015