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

[burek]

[00:45] <cone-338> ffmpeg.git 03Mark Boorer 07master:352756ecae8f: avformat/movenc: respect color_range when encoding dnxhd.
[01:44] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:98eab9815961: avdevice/pulse_audio_dec: reimplement using the non simple API
[03:17] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:c8b2cf49966f: avcodec/mpegvideo: flip motion vector visualization for backward motion vectors
[03:29] <Compn> michaelni : you looked at the t263 (h263) motion vectors ? 
[03:29] <Compn> we have samples in repo
[03:37] <michaelni> Compn, i looked at one files visualization otput and the vectors looked like all 0,0
[03:37] <michaelni> what reason do we have to belive that this doesnt represent the file content?
[03:38] <michaelni> i dont like searching bugs where theres no evidence that there is a bug
[03:44] <Compn> i was thinking it was the content 
[03:44] <Compn> not a bug in the code
[03:44] <Compn> so thanks for looking, it confirms my guess
[04:16] <michaelni> Compn, btw, i dont understand what that guy wants to do with the motion vectors (if there where any non 0 ones)
[04:17] <Compn> lol michaelni , i think he wants to print out the image with the little arrows on it
[04:17] <Compn> and then go in a court room and say 'here you can see his hand move, indicating he purposefully shot the defendant'
[04:17] <Compn> something like that
[04:18] <Compn> just using visual motion vectors as a visual aid to show his narrative to a jury/judge
[04:19] <Compn> usa has some pretty bad court system... you can tell if you ever watched one of those law and order tv shows
[04:56] <Timothy_Gu> Anybody here who knows who Rodeo is?
[05:00] <Timothy_Gu> BTW we should set up some kind of IRC nick database, on wiki probably. Who knows that Daemon404 is Derek or ubitux is Clément, even if you check whois.
[05:00] <Timothy_Gu> Not every nick is like mine
[05:03] <Timothy_Gu> BTW2, ubitux, do you still want to make a release note? If not I can probably make one
[05:03] <Compn> Timothy_Gu : you sound like a govt agent! :P
[05:04] <Timothy_Gu> Compn: no seriously it's really annoying, especially when Michael loves referring to people by their nicks on commit messages
[05:05] <Compn> isnt it their commit nick too ?
[05:05] <Compn> sometimes
[05:05] <Compn> or was back in svn days. i guess i'm in the past
[05:05] <Timothy_Gu> Yep
[05:06] <Timothy_Gu> Git (and I) like real names
[05:06] Action: Compn uses nickname on git commit
[05:08] <Timothy_Gu> People who use pseudonym thruout (like you) are at least identifiable, people who use the same nick anywhere is OK too (like ubitux); but who knows that durandal_1707 == richardpl == PBM?
[05:22] <michaelni> we could add such a list to the wiki
[05:32] <Compn> Timothy_Gu : maybe some people like their multiple personalities :P
[05:32] Action: Compn just arguing for fun
[05:32] <Compn> do whatever tim
[07:20] <ubitux> Timothy_Gu: yes i want to apply the release notes patch
[07:20] <ubitux> Timothy_Gu: but i don't remember if it was OK'ed
[07:20] <ubitux> and it was linked to the pkg-config libx264 thing, with CE not agreeing unless we keep the freaking hack somehow
[07:31] <ubitux> michaelni: are you fine with the new Changelog for 2.3?
[08:28] <cone-805> ffmpeg.git 03Carl Eugen Hoyos 07master:e4dfc3f9b887: Fix wmv1 decoding if no other msmpeg4-related decoder was compiled.
[08:52] <cone-805> ffmpeg.git 03Carl Eugen Hoyos 07master:d6e7881c2e60: Fix wmv1 encoding if all other msmpeg4-related encoders were disabled.
[09:18] <ubitux> so, when are we getting emoji in subtitles specifications?
[09:19] <wm4> emojis are already in unicode
[09:20] <wm4> so you can use them in srt, ass, etc.
[09:20] <ubitux> colored emoji i mean
[09:20] <wm4> that is part of font rendering
[09:20] <wm4> though libass for one couldn't even output such characters
[09:20] <ubitux> i'm looking forward animated colored emoji in subtitles
[09:21] Action: wm4 puts ubitux on his death list
[09:21] <ubitux> (trending link atm: http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/)
[09:21] <ubitux> wm4 ;)
[09:22] <wm4> god they're fugly
[09:22] <wm4> and lol pngs in fonts
[09:23] <ubitux> xface wasn't supporting colors
[09:23] <ubitux> so they picked png
[09:32] <ubitux> FT seems to support the adobe/google emoji system but i don't see anything about that one
[09:32] <ubitux> that's sad :(
[14:36] <michaelni> ubitux, about new changelog, it looks better, not sure if the symbols will display ok for most though, also the old changelog should be kept, people may upgrade less often than after every release so they may be interrested in more than the most recent changelog, also the Changelog could benefit from a maintainer
[14:37] <michaelni> symbols didnt display correctly for me in mutt for example
[14:37] <ubitux> huh? isn't it a terminal problem?
[14:37] <ubitux> like missing a char in your font or something?
[14:37] <ubitux> but well yeah ok
[14:37] <ubitux> about the changelog i don't mind moving it in doc/Changelog
[14:38] <ubitux> but what are you doing to do with the current Changelog after the release?
[14:38] <michaelni> yes, very likely term issue
[14:38] <ubitux> s/doing/going/
[14:40] <ubitux> (moving it to doc/Changelog.old*)
[14:40] <ubitux> so, doc/{Changelog.old,Changelog.2.3.old,Changelog.2.4.old,...} ?
[14:43] <michaelni> as a user i tended to read changelogs (like from debian) from the point of th new version to what i had installed previously. not sure if multiple files are that convenient but thats just one person and one usecase, i dont know what others use the chnagelog for
[14:43] <ubitux> i can group them call in a directory
[14:43] <ubitux> and you'll cat doc/Changelog/*|less
[14:44] <michaelni> thats classic floss design (useless to 99% of users)
[14:44] <ubitux> i'm pretty sure 99% of users want to see lastest features...
[14:45] <michaelni> yes, whats the purpose of the chnagelog
[14:45] <michaelni> what usecases is it used in ?
[14:49] <michaelni> one usecase i could imaging is a user trying to awnser "should i upgrade", the user might be running ffmpeg 1.2 and might want to know what features she gains from ffmpeg 2.3 in relation to 1.2 or rather if anything she cares about has been fixed/improved
[14:52] <michaelni> anyone knows other use cases for changelogs ?
[14:53] <ejl> can be useful for determining what version a change happened in
[14:53] <Daemon404> that would be in docs/api*
[14:53] <Daemon404> which is still kidna useless because it contains no real details
[15:32] <ubitux> so should i reformat the whole file?
[15:32] <ubitux> the point was to keep a standalone clean Changelog/Release note
[15:32] <ubitux> for each release
[15:33] <ubitux> we can wait/discuss it for next release if people don't want it anwyay
[15:34] <ubitux> the initial point was to have a proper way of documenting behaviour changes
[15:34] <ubitux> but since CE kind of veto the libx264 change..
[15:35] <Daemon404> fuck CE
[15:35] <Daemon404> literally everyone but him is for it
[15:35] <Daemon404> its like 20-to-1
[15:35] <Daemon404> at what point does this not make pushing it OK?
[15:35] <Daemon404> 10000-to-1?
[16:10] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:f32c5d1a8dae: avcodec/mpegvideo: clip mv visualization arrows so that their direction is maintained
[16:12] <ubitux> michaelni: how can we know to what frame the mv is applied?
[16:12] <ubitux> from* what frame actually
[16:13] <michaelni> in pre h264 its last/next_picture (except for interlaced mpeg2 which has some special cases)
[16:13] <ubitux> mmh
[16:14] <ubitux> picture in the sense "AVFrame"?
[16:14] <ubitux> i thought it could refer to something like ±3 frames
[16:17] <michaelni> typedef struct Picture (which contains a AVFrame too)
[16:18] <michaelni> +-n frames in presentation order
[16:18] <michaelni> but all these pre h264 decoders work with very few picture buffers
[16:18] <michaelni> so that the last/next arent neccesarily the immedeatly last/next frames to display
[16:19] <ubitux> is it possible to reconstruct easily that information?
[16:20] <ubitux> since i'll probably store a field such as ±N in the frame side data to say to which frame the mv is from
[16:20] <ubitux> (temporal indication of previous/next frames)
[16:20] <ubitux> if that makes any sense
[16:21] <michaelni> if the pic structs dont contain a frame number you could add one which should allow keeping track of things or use pts, maybe theres also a easier way
[16:22] <michaelni> also you will need 2x2 such fields for pre h264 (to handle both fields for interlaced mpeg2)
[16:22] <michaelni> or maybe it can be inferred from just 2 values dunno
[16:23] <ubitux> speaking of this, isn't there a slice system in h264? like, a frame being allowed to be split in N slices? (how much max?)
[16:23] <michaelni> yes, dunno about max
[16:23] <ubitux> maybe i should read the specs instead of wasting your time though
[16:24] <michaelni> yes, but keep headache pills ready if you do
[16:24] <ubitux> :(
[16:24] <mraulet> ubitux: enjoy
[16:24] <mraulet> 500 pages :-)
[16:25] <mraulet> michaelni: I have most of Rext implemented
[16:25] <mraulet> HEVC Rext
[16:26] <michaelni> anything i should cherry pick / merge ?
[16:26] <mraulet> not right now
[16:26] <michaelni> ok
[16:26] <mraulet> I will do a clean version
[16:26] <michaelni> ok
[16:26] <ubitux> speaking of this
[16:27] <ubitux> aac improvements are still not merged?
[16:27] <mraulet> I got a headache with cross component prediction ^^
[16:29] <michaelni> is there a patch or pull req for aac ? 
[16:30] <michaelni> last i remember the author said "wait
[16:33] <ubitux> yeah :(
[16:39] <iive> are you talking about improvements of the aac encoder?
[16:40] <ubitux> yes
[16:58] <iive> maybe you should encourage the author to allow the current code to be merged, even if it is not perfect?
[16:58] <ubitux> done several times
[16:58] <ubitux> he's working on it
[16:59] <iive> have the changes piled up?
[16:59] <iive> i mean, have the patch got really huge?
[17:03] <ubitux> iive: #2686
[17:03] <ubitux> judge by yourself
[17:10] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:b83e0903ec4d: avformat/m4vdec: raise threshold slightly for detection
[17:51] <jamrial> michaelni: adding io.h to libavutil/bprint.c might fix the current msvc compilation failure
[18:17] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:31d49db75eea: avutil/bprint:ædd io.h, try to fix msvc build
[18:36] <ac_slater> hey all, I'm interesting in making a RTP mux/demux pair for a payload type I'm working on. I have a few questions though. From looking through the source, it appears that RTP delivery only supports 1 stream. Is this true? I was planning on muxing multiple streams. Any advice is appreciated.
[18:39] <ac_slater> interested * 
[18:40] <ac_slater> (I hope this pertains to ffmpeg development as I plan to release this code to the project
[18:40] <ac_slater> )
[19:02] <michaelni> ac_slater, yes IIRC its 1 stream only
[19:32] <ac_slater> michaelni: sigh. I guess I could mux into am mpeg2ts first
[19:32] <michaelni> or you have 2 rtp streams
[19:33] <ac_slater> michaelni: on different ports, etc - sure. But doesn't this ruin all coordination?
[19:37] <ac_slater> michaelni: does RTSP support more than 1 stream?
[19:40] <ac_slater> michaelni: looks like it does
[19:41] <Compn> yes it does
[19:42] <Compn> streams are seperated i think as well
[19:48] <ac_slater> Compn: interesting. So, I really need RTP to do multistream muxing with RTSP. I cant see the multi-instance RTP streaming working out too well if I want my stream to play outside of the ffmpeg libraries. 
[19:48] <ac_slater> without* 
[19:48] <ac_slater> without RTSP * 
[19:59] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:e36916a63f6f: avcodec/pthread_frame: fix setting hwaccel with threads and get_format()
[20:19] <cone-730> ffmpeg.git 03Oliver Fromme 07master:a32dcaaaf809: avcodec/dvdsubenc: Add dvdsub workaround for some players
[21:27] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:9af59db6ec0e: avcodec/roqvideoenc: More verbose warning about no power of 2 dimensions
[21:27] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:76a35f7830d1: avcodec/roqvideoenc: Print the correct max resolution
[21:36] <cone-730> ffmpeg.git 03Anton Khirnov 07master:abda15a99052: cdg: set the keyframe flag on the first packet
[21:36] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:714d9bd6ee2f: Merge commit 'abda15a990527557c20848f6ca2f82eb85e76dc9'
[21:43] <cone-730> ffmpeg.git 03Anton Khirnov 07master:c9c1265c5291: avformat: update muxing doxy
[21:43] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:4b13ec69c6a2: Merge commit 'c9c1265c52910578d3db1a6205c85b91ead0903f'
[21:57] <cone-730> ffmpeg.git 03Anton Khirnov 07master:3f3232a371cc: avconv: set the output stream timebase
[21:57] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:8e7c8325d202: Merge commit '3f3232a371cc88696184d9aef1f812656264e56c'
[21:57] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:9098f0ecd7bf: ffmpeg: remove common factors from copied timebase
[22:37] <cone-730> ffmpeg.git 03Anton Khirnov 07master:f6ee61fb0548: lavc: export DV profile API used by muxer/demuxer as public
[22:37] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:1b58f1376132: Merge commit 'f6ee61fb05482c617f5deee29a190d8ff483b3d1'
[22:47] <cone-730> ffmpeg.git 03Anton Khirnov 07master:d5cf5afabbf4: adxdec: get rid of an avpriv function
[22:47] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:e932ae594056: Merge commit 'd5cf5afabbf43f00283e70b12afbe1da030d85b6'
[23:09] <cone-730> ffmpeg.git 03Anton Khirnov 07master:b8604a976128: oggparsecelt: do not set AVCodecContext.frame_size
[23:09] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:d52f874c7fa7: Merge commit 'b8604a976128ffbd316653cdec11ba487f1025bb'
[23:18] <cone-730> ffmpeg.git 03Anton Khirnov 07master:a14b61658c33: mtv: do not set sample_rate for video
[23:18] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:81babc432ab2: Merge commit 'a14b61658c3302081ea5da3ea65b7d9f7b4fb2eb'
[23:25] <cone-730> ffmpeg.git 03Anton Khirnov 07master:edb1af7c466e: mov: free the dv demux context with avformat_free_context()
[23:25] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:73b1283012cf: Merge commit 'edb1af7c466ebb28bfdb0c076e498e527b43d24f'
[23:30] <cone-730> ffmpeg.git 03Anton Khirnov 07master:27c1f82f5619: nsvdec: remove commented out cruft
[23:30] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:57fa9e97424d: Merge commit '27c1f82f561932c83191bcd3e70e0cb1712485ba'
[23:40] <cone-730> ffmpeg.git 03Anton Khirnov 07master:650d384048ed: yuv4mpegenc: do not access AVCodecContext.coded_frame
[23:40] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:f233666880af: Merge commit '650d384048ed42579cc6d67bf32a94b468c0b6cb'
[23:45] <cone-730> ffmpeg.git 03Anton Khirnov 07master:0307cc2253e7: rtpdec: pass an AVFormatContext to ff_parse_fmtp()
[23:45] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:19b9e07ef5fd: Merge commit '0307cc2253e76772b1c645ac6117d08da87a147c'
[23:56] <cone-730> ffmpeg.git 03Andrew Kelley 07master:33a7b453a8e1: doc: mention option to mix shared/static libraries
[23:56] <cone-730> ffmpeg.git 03Michael Niedermayer 07master:e8a966e361a7: Merge commit '33a7b453a8e1f090c694ea4f36769dc837be88f0'
[00:00] --- Thu Jul 10 2014