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

[burek]

[00:00] <durandal_1707> ff_raw_pix_fmt_tags should be renamed to something like avpriv_raw_pix_fmt_tags
[01:19] <cone-597> ffmpeg.git 03Piotr Bandurski 07master:f9a8eeb08c4c: iff/deep: fix rle32 on big-endian
[04:59] <cone-394> ffmpeg.git 03Michael Niedermayer 07master:11c99c78bafa: h264: check the pixel format directly and force a reinit on mismatches.
[11:42] <durandal_1707> why is context missing when av_log is called from .write_header in muxer? it should be present and in distinct color.
[12:11] <cone-913> ffmpeg.git 03Paul B Mahol 07master:8a6ae87b9915: lavc: move deprecated audio_resample* bellow
[13:47] <cone-913> ffmpeg.git 03Luca Barbato 07master:f550583c00e2: bfin: update VP3 idct
[13:47] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:8265c0f43a44: Merge commit 'f550583c00e231b587d8ef98451cfbb6b6561eb6'
[13:55] <cone-913> ffmpeg.git 03Diego Biurrun 07master:438ea561ade1: bfin: Separate VP3 initialization code
[13:55] <cone-913> ffmpeg.git 03Diego Biurrun 07master:c59211b437aa: x86: Simplify some arch conditionals
[13:55] <cone-913> ffmpeg.git 03Anton Khirnov 07master:f1c395944ce9: eatgv: use fixed-width types where appropriate.
[13:55] <cone-913> ffmpeg.git 03Anton Khirnov 07master:098eed95bc1a: mdec: merge mdec_common_init() into decode_init().
[13:55] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:14aa358c20c2: Merge commit '098eed95bc1a6b2c8ac97f126f62bb74699670cf'
[14:05] <cone-913> ffmpeg.git 03Anton Khirnov 07master:f713411d4cfb: mdec: cosmetics, reformat
[14:05] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:f02033b98b75: Merge commit 'f713411d4cfbd9c467aeda77b16ca6bc4db55d10'
[14:18] <cone-913> ffmpeg.git 03Anton Khirnov 07master:30d62507cd9c: mdec: return meaningful error codes.
[14:18] <cone-913> ffmpeg.git 03Anton Khirnov 07master:e6da5d215b1f: mimic: remove a pointless cast.
[14:18] <cone-913> ffmpeg.git 03Anton Khirnov 07master:aec50f79e746: rawdec: use AVPALETTE_SIZE instead of magic constants.
[14:18] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:31d8d61f590e: Merge commit 'aec50f79e7460340a148a3096fe212d67edc2c64'
[14:24] <cone-913> ffmpeg.git 03Anton Khirnov 07master:729b37149c9c: mvi: set framerate
[14:24] <cone-913> ffmpeg.git 03Anton Khirnov 07master:e6b1c3bbe708: pthread: make ff_thread_release_buffer idempotent.
[14:24] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:3c8085dc4250: Merge commit 'e6b1c3bbe7082c71ea8ee8ac83698c156c9e4838'
[14:39] <cone-913> ffmpeg.git 03Anton Khirnov 07master:231fd1ed3932: utvideoenc/v410enc: do not set AVFrame.reference.
[14:39] <cone-913> ffmpeg.git 03Anton Khirnov 07master:47318953ddfe: mpegvideo: remove some unused variables from Picture.
[14:39] <cone-913> ffmpeg.git 03Anton Khirnov 07master:76e74e4831f0: h264: remove obsolete comment.
[14:39] <cone-913> ffmpeg.git 03Anton Khirnov 07master:f81c37e40fe3: vf_delogo: fix an uninitialized read.
[14:39] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:d1bbd304bf60: Merge commit 'f81c37e40fe3236d54da12aef9cdba48ba70ec31'
[15:19] <durandal_1707> ubitux: ping
[15:20] <cone-913> ffmpeg.git 03Anton Khirnov 07master:7194330bcd6d: vf_delogo: fix copying the input frame.
[15:20] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:5068bcda95c2: Merge remote-tracking branch 'qatar/master'
[15:21] <durandal_1707> ubitux: pin3
[15:35] <ubitux> durandal_1707: pong
[15:35] <mateo`> ubitux: \o/
[15:36] <ubitux> not for long ;)
[15:39] <durandal_1707> ubitux: i was just wondering about making showspectrum more useful
[15:40] <durandal_1707> more channels, etc like what SoX spectrogram have
[15:41] <ubitux> the point of showspectrum was to port the feature from ffplay, feel free to do whatever you want to it as long as a "compat" mode is still available for when ffplay will actually use it
[15:41] <durandal_1707> i could write new filter...
[15:41] <ubitux> what for?
[15:42] <durandal_1707> compat mode? where all channels are calculated but only 2 displayed
[15:42] <durandal_1707> ubitux: spectrogram
[15:42] <ubitux> by compat mode i mean something that is close enough to the original
[15:43] <ubitux> if you actually improve the output i don't think anyone will complain
[15:45] <durandal_1707> well idea is to render all channels
[15:45] <durandal_1707> and custom/better colors
[15:46] <durandal_1707> and also different algos that calculate spectrum: kaiser/rectangular/hamming...
[15:46] <durandal_1707> also to output single image of whole song
[15:47] <ubitux> sounds like a good idea
[15:48] <mateo`> great idea :)
[15:49] <ubitux> just keep a playback mode like currently, i don't mind better and more advanced channel colors
[15:50] <ubitux> i guess you might want to make a color-by-intensity instead of channels, but please keep a channel one :)
[15:50] <ubitux> (optional i mean)
[15:51] <mateo`> http://blog.dubspot.com/files/2011/02/Spectrum1.png < this kind of spectrum rendering is on my todolist
[15:55] <durandal_1707> mateo`: that is improved showwaves
[15:57] <mateo`> durandal_1707: right :)
[16:20] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:036b9ee1c959: oggenc: fix "oggstream may be used uninitialized in this function" warning
[16:20] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:ebe368d5d82c: ac3enc: fix 'warning: block0 may be used uninitialized in this function'
[16:20] <divVerent> durandal_1707: personally, I say: good idea
[16:20] <divVerent> the "compat mode" even sounds quite simple
[16:21] <divVerent> option 1: b/w (or still colored), different channels go to different screen areas
[16:21] <divVerent> option 2: all channels overlap, colors get added (like now)
[16:22] <divVerent> outputting single image for whole song - I'd love that feature, just doesn't sound like something a filter would do. Maybe if the filter has an output file arg, it could additionally do that
[17:10] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:3cd9849d9c24: eval: fix 'warning: ignoring return value of strtod, declared with attribute warn_unused_result'
[17:10] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:df92ac18528b: r3d: fix division by 0 with 0 sample rate
[18:07] <durandal_1707> divVerent: it is just matter of stream duration, you set one and stop filter when it reaches right end...
[18:23] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:99b1b2b1c659: r3d: check that sampling rate is non negative.
[18:23] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:f67a0d115254: huffyuvdec: Check init_vlc() return codes.
[18:23] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:4420b414420e: huffyuvdec: check for and propagate failures from inside generate_joint_tables()
[18:45] <durandal_1707> thing is that improving showspectrum is much more work that writing new filter from scratch
[19:21] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:0dfc01c2bbf4: huffyuvdec: Skip len==0 cases
[19:49] <divVerent> durandal_1707: hehe, right... if you give the duration in advance, the filter can operate normally
[19:56] <durandal_1707> divVerent: currently it displays up to two channels at same time
[19:57] <durandal_1707> divVerent: how would you display >2 channels in same row?
[20:02] <michaelni> if you have 8 channels one could draw something similar to ffplays rdft in 8dimensional colorspace instead of the common 3dim RGB and could then project it to 3 dimensions to be able to display it ...
[20:04] <michaelni> such projection should likely preserve luminance (as overall loudness)
[20:04] <divVerent> durandal_1707: color overlap
[20:04] <divVerent> like, for 3 channels, r g b
[20:04] <divVerent> for more, I'd distribute them along hue evenly
[20:05] <divVerent> this would be method 1
[20:05] <divVerent> method 2 would be what sox does
[20:05] <durandal_1707> really? my ffplay plays only mono or stereo and output is same as if I play only 2 channels
[20:05] <divVerent> first 6th of height is channel 1
[20:05] <divVerent> then next 6th is channel 2
[20:05] <divVerent> etc.
[20:05] <divVerent> durandal_1707: currently it only supports 2 channels
[20:05] <divVerent> and usually the spectrum is so similar for both channels
[20:05] <divVerent> that you see no coloring
[20:05] <divVerent> try Bohemian Rhapsody to see it ;)
[20:05] <durandal_1707> divVerent: sox does what i posted patch now
[20:06] <divVerent> thing is, it doesn't SOUND very hard to both support sox method and old ffplay method at the same time
[20:06] <divVerent> you always build an array of screen height size
[20:06] <divVerent> for sox method, you divide it into n parts
[20:06] <durandal_1707> divVerent: i see (a + b) /2 colors ... nothing spectactular ..
[20:06] <divVerent> for ffplay method, you use a single part for all
[20:06] <durandal_1707> and what you get?
[20:06] <divVerent> but otherwise, you always color the spectrum value by the channel color
[20:06] <divVerent> and add up
[20:07] <durandal_1707> i just add numbers and say here is color?
[20:07] <divVerent> "sort of"
[20:08] <divVerent> right
[20:08] <divVerent> currently, R is a, G is b, B is (a+b)/2
[20:08] <divVerent> so the color of left channel is #ff0080 (reddish-pink)
[20:08] <michaelni> for side by side display it might make sense to put the left channels left, the right channels right and the center/lfe in the middle
[20:08] <divVerent> the color of blue channel is #00ff80 (greenish-cyan)#
[20:08] <michaelni> front up and back down on the screen ...
[20:08] <divVerent> michaelni: agreed
[20:08] <divVerent> the same rotated by 90 degrees may actually be better
[20:08] <divVerent> but most programs display spectrum horizontally
[20:09] <divVerent> so time axis goes from left to right
[20:09] <divVerent> personally I'd actually prefer it the other way, time axis from top to bottom and scrolling up
[20:09] <divVerent> as that means more accuracy for the pitch
[20:10] <durandal_1707> you just have wrong monitor
[20:10] <divVerent> hehe
[20:10] <divVerent> actually, I could rotate mine
[20:10] <divVerent> it does support it
[20:10] <divVerent> and I have xrandr too...
[20:10] <divVerent> but I am used to wider-than-high
[20:11] <divVerent> but anyway, even though I personally prefer the rotated view
[20:11] <divVerent> I would rather recommend that ffmpeg use the standard view
[20:11] <divVerent> as most audio guys are used to that view
[20:11] <divVerent> given 99% of audio editors use it
[20:11] <divVerent> i.e. frequency from bottom to top, time from left to right
[20:11] <divVerent> for my personal preference, I can always add a rotate filter
[20:12] <durandal_1707> patch welcome, i implement for what i have motivation and other too if code is soo good that small changes....
[20:12] <divVerent> sure
[20:12] <divVerent> actually, this may be something I would want to do... have a screenshot of what you currently have?
[20:13] <durandal_1707> same as sox but mono and sox have channels listed in different order
[20:13] <divVerent> #define IM(ch) data[ch][2*y + 1]
[20:13] <divVerent> this BTW is hideous ;)
[20:13] <durandal_1707> so next thing to do is colors...
[20:13] <divVerent> in the old code
[20:13] <divVerent> basically, a hidden macro parameter "y"
[20:14] <durandal_1707> i did not wrote that code 
[20:14] <divVerent> not saying you did
[20:15] <divVerent> probably nobody knows anymore who wrote it originally
[20:15] <divVerent> as it stems from ffplay
[20:15] <divVerent> as for colors, a constructive idea... what if the filter output yuv444p instead? ;)
[20:15] <durandal_1707> its like: lets implement some nice feature but on end you implement only 10% of it
[20:15] <divVerent> then you could use Y for intensity, and calculate U and V based on color
[20:16] <divVerent> advantage versus RGB would be that different colors would have roughly the same intensity
[20:16] <divVerent> unlike e.g. RGB, where #00ff00 is a lot brighter than #0000ff
[20:16] <divVerent> or did you already do that, as it also lets you be lazy for grey output? ;)
[20:17] <divVerent> disadvantage is that I don't currently know a good hue -> YUV conversion
[20:17] <divVerent> as for what I have in my head, I'd evenly space out the colors in hue
[20:18] <durandal_1707> sox use pal8, so only 256 colors
[20:18] <divVerent> ah, yes
[20:18] <divVerent> that's the other way to do colors
[20:18] <divVerent> to show intensity by color too
[20:18] <divVerent> right, I forgot - sox does that
[20:18] <durandal_1707> i would prever something more poverful
[20:18] <durandal_1707> *prefer
[20:18] <durandal_1707> like 16bit bps
[20:19] <divVerent> BTW, out of curioisity... would it make any sense to show the phase (direction of re, im)?
[20:19] <divVerent> probably not
[20:19] <durandal_1707> for double sample format...
[20:19] <divVerent> sox kinda "solves" it by having a different scale
[20:20] <divVerent> ffmpeg uses sqrt() currently, didn't check what sox does, but it seems logarithmic
[20:20] <divVerent> which kinda solves the accuracy issue
[20:25] <durandal_1707> ubitux wants it to mimic in some mode, what ffplay does, which limits what i can do without making code even more convoluted
[20:26] <divVerent> I didn't see your code, but to me it looks possible to unify it
[20:26] <divVerent> if you want, I can try bringing the old mode back "as cleanly as possible"
[20:26] <divVerent> tomorrow
[20:26] <durandal_1707> so what is best formula to map X-channels into 24 bit rgb value?
[20:28] <durandal_1707> divVerent: if you are subscribed to devel ml you can see it ....
[22:55] <cone-913> ffmpeg.git 03PaweB Hajdan, Jr 07master:1d81f7448c8a: dict.c: use av_mallocz instead of av_realloc
[22:55] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:dc8dd2f6e972: sanm: Check MV before using them.
[23:07] <saste> michaelni, about my eval doc patches? should I push them?
[23:07] <saste> nobody's going to review them anyway (but - maybe - you)
[23:25] <durandal_1707> michaelni: the sanm commit looks wrong
[23:27] <durandal_1707> how are you sure that there in nothing between prev and frm2?
[23:31] <durandal_1707> there is already code that check motion vectors...
[23:43] <durandal_1707> michaelni: are you aware of this?
[23:47] <michaelni> durandal_1707, what can be between prev2 and frm2 ?
[23:47] <durandal_1707> anything
[23:47] <durandal_1707> it is not real fix
[23:47] <durandal_1707> frm0/1/2 do not be conitinous in memory/ one after another
[23:48] <michaelni> prev2 points in frm2
[23:48] <durandal_1707> so you could make frmX to come one after another
[23:49] <michaelni> uint8_t *prev2 = (uint8_t*)ctx->frm2;
[23:50] <michaelni> the MV could be checked differently of course but i dont see a problem with how its checked now, this doesnt mean there is none, if theres an issue please explain
[23:52] <durandal_1707> you are indeed right, sorry for wasting time
[00:00] --- Wed Jan 30 2013