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

[burek]

[00:25] <cone-796> ffmpeg.git 03wm4 07master:8b6136d3d18f: vaapi: switch ff_vaapi_get_surface_id from Picture to AVFrame
[00:25] <cone-796> ffmpeg.git 03Michael Niedermayer 07master:19139d8516dd: Merge remote-tracking branch 'qatar/master'
[00:34] <wm4> now vdpau works again
[03:46] <cone-558> ffmpeg.git 03Michael Niedermayer 07master:45ad7bc42328: avcodec/snowdec: provide information about the wavelet with -debug 1
[03:46] <cone-558> ffmpeg.git 03Michael Niedermayer 07master:1cd107f63792: avcodec/x86/snowdsp: add missing clobbers to inner_add_yblock_bw_8_obmc_16_bh_even_sse2() and inner_add_yblock_bw_16_obmc_32_sse2()
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:87d335c00756: avcodec/parser: reset indexes on realloc failure
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:ea23dcc4986e: avfilter/ff_insert_pad: fix order of operations
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:84e1aa7768a2: avcodec/jpeglsdec: check err value for ls_get_code_runterm()
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:c44ac4d81e86: dnxhdenc: fix mb_rc size
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:e0f351a97955: avcodec/vmnc: Check  that rectangles are within the picture
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:605c3f051540: avcodec/vc1: reset fcm/field_mode in non advanced header parsing
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:356f8634e991: wmalosslessdec: make mclms arrays big enough for whats written into them.
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:954ce59a0abb: avcodec/wmalosslessdec: fix mclms_coeffs* array size
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:d234e1d333c9: avformat/mpegtsenc: Check data array size in mpegts_write_pmt()
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:573d5fdedae7: avcodec/msrle: use av_image_get_linesize() to calculate the linesize
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:85162a60b8f9: avcodec/snow: split block clipping checks
[05:52] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:3926ebc7029d: vorbisdec: Check bark_map_size.
[05:57] <cone-558> ffmpeg.git 03Michael Niedermayer 07release/0.9:d55059d048bd: update for 0.9.4
[06:20] <cone-558> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.9.4': unknown revision or path not in the working tree.
[06:20] <cone-558> Use '--' to separate paths from revisions
[06:20] <cone-558> refs/tags/n0.9.4:HEAD: avcodec/x86/snowdsp: add missing clobbers to inner_add_yblock_bw_8_obmc_16_bh_even_sse2() and inner_add_yblock_bw_16_obmc_32_sse2()
[09:40] <ubitux> BBB: so, i grabbed the raw of etv, i'll try to remake the encode in the next days
[09:40] <ubitux> ...if i figure out how bluray supports works in ffmpeg
[09:59] <ubitux> BBB: btw, i wonder if we should test with a --tune grain for that sample
[10:14] <ubitux> ah but well that won't do with ssim tuning
[10:28] <j-b> 'morning
[11:46] <BBB> ubitux: you want to re-encode for 5 days again?
[11:46] <ubitux> it's in progress
[11:46] <BBB> (x N encodes)
[11:46] <ubitux> :p
[11:46] <ubitux> i'm redoing all the encode currently
[11:47] <BBB> well that's a ton of work, but I guess it's good
[11:47] <BBB> we should write a faster encoder ;)
[11:47] <ubitux> it's fine the script is already done
[11:47] <ubitux> i just have to wait
[11:48] <ubitux> i've roughly the same sample (maybe a few frame mismatch)
[11:48] <ubitux> cropped the same, so same resolution
[11:49] <ubitux> that should provide more accurate results :)
[11:49] <ubitux> and we'll get fixed on the high bitrate quirck
[11:59] <BBB> yeah, that was the one where x264 beat libvpx-vp9, right?
[12:11] <ubitux> BBB: yes
[12:12] <ubitux> the sample is about 4 seconds off the previous one
[12:12] <ubitux> shouldn't affect much the results
[12:21] <BBB> as long as you re-do the x264 encodes also, it's fine, yes
[12:21] <BBB> but you were going to do that already so I suppose it's fine
[12:24] <ubitux> yes i'm redoing all of them
[12:39] <Compn> people love fighting about benchmarks :D
[12:39] <Compn> big companies like nvidia and ati even spend time to cheat at 3d benchmark software :P
[12:43] <ubitux> it's not benchmark here, it's all about the quality of then encode
[12:43] <ubitux> s/then/the/
[12:43] <nevcairiel> you could also "benchmark" the quality, its not always about speed
[12:43] <ubitux> the results were weird and we wanted to know if that was because the source was h264
[12:45] <BBB> yeah, I think it's a fair concern
[12:45] <BBB> so good to check
[15:22] <cone-58> ffmpeg.git 03Anshul Maheshwari 07master:6d25e90262e3: doc/examples/avcodec: information regarding gop_size ignored if frame->pic-type is AV_PICTURE_TYPE_I
[15:28] <saste> WTF why was it renamed?
[15:30] <nevcairiel> what was renamed?
[15:32] <saste> encoding_decoding -> avcodec
[15:32] <saste> anyway, i don't care
[15:58] <michaelni> saste, see b339182eba34f28de5f1a477cdd2c84f1ef35d90
[15:59] <michaelni> i can rename it back if you prefer 
[15:59] <saste> michaelni, i'll send a patch in case i feel the urge
[16:05] <Waraqa> Hi, Who can help me with my problem?
[16:06] <Waraqa> I opened ticket #3485
[16:15] <ubitux> it's just been closed
[16:15] <Waraqa> I know but I need help
[16:15] <ubitux> upgrade?
[16:15] <Waraqa> no, the video doesn't work with vlc also
[16:16] <ubitux> vlc is probably using that ffmpeg version as well
[16:16] <ubitux> just upgrade
[16:16] <ubitux> also, it's a #ffmpeg question probably
[16:16] <Waraqa> Ok, I will move there
[17:11] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:9dca02ee5411: ffmpeg: dont call exit_program() from a signal hander
[17:57] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:db55365d0f93: configure: Try to fix detection of ARM Compiler 5.04
[18:41] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:c3272674c943: avcodec/mpegvideo: make mc_mb_var_sum_temp / mb_var_sum_temp 64bit
[18:42] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:e92a78a4095d: avcodec/mpegvideo: make mc_mb_var_sum / mb_var_sum 64bit
[18:42] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:b4356c9cc281: avcodec/ratecontrol: make (mc_)mb_var_sum(_last) 64bit
[18:42] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:2fd14f062cfc: avcodec/snowenc: allow larger mb variances
[18:59] <llogan> or an info can say "-qscale is ignored with libx264. Use -crf instead. Default of -crf 23 will be used." i don't know how to implement that though.
[19:01] <llogan> and 99% of users shouldn't be messing around with -qp, so defnintely don't map to that
[20:25] <J_Darnley> llogan:  Are you working on a patch for the qscale-libx264 ticket?
[20:36] <llogan> J_Darnley: no. please do so if you would like to.
[20:44] <cone-58> ffmpeg.git 03wm4 07master:76c8fbc5f22c: http: never send 'Cookie: (null)' to the server
[21:40] <J_Darnley> llogan: You suggested "-qscale is ignored with libx264. Use -crf instead. Default of -crf 23 will be used." on trac.
[21:40] <J_Darnley> I am using "-qscale is ignored with libx264, use -crf instead. Default of -crf 23 will be used.\n"
[21:40] <J_Darnley> Do you or anyone else want to make sueggestions here?
[21:41] <J_Darnley> *suggestions
[21:46] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:8a5ea5b9efca: avcodec/snowenc: simplify spatial_decomposition_count seting code
[21:46] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:296aa4ac0168: avcodec/snowdec: return more specific error codes
[21:46] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:2fb388fc9d0f: avcodec/snowdec: forward error codes
[21:46] <cone-58> ffmpeg.git 03Michael Niedermayer 07master:1b4f2fb165a3: avcodec/snowdec: also print qbias and mvscale in debug output
[21:54] <J_Darnley> Wait a minute... Why isn't ffmpeg printing any colours in the log
[21:57] <J_Darnley> WTF!  Who made cygwin be treated like a native Windows application?
[22:21] <J_Darnley> If anyone would like to see my current proposal: https://gitorious.org/ffmpeg/jdarnley-ffmpeg/commit/049ed4fe09189b67405bd149e0523dd0460fe5fd
[22:21] <J_Darnley> 1 - It is a warning
[22:22] <J_Darnley> 2 - It is just shoved in at the top on the init function
[22:25] <michaelni> assuming crf and qp is set then somethig else than 23 would be used
[22:26] <J_Darnley> Ah, true
[22:26] <J_Darnley> Do you have a suggestion for that case?
[22:27] <J_Darnley> Reading the user set crf value and printing that?
[22:36] <J_Darnley> michaelni: How about this "-qscale is ignored with libx264, using -crf %f instead." after we set the libx264 crf parameter?
[22:37] <michaelni> LGTM
[22:37] <michaelni> if it works ...
[22:39] <J_Darnley> I believe so.  If only -qscale is given 23 (x264's default) is printed.  If both -qscale and -crf are given the crf value is printed.
[22:47] <J_Darnley> Okay done.  Do you want me to send a patch to the mailing list?
[22:51] <michaelni> yes  thats an option
[22:55] <J_Darnley> Well, would you prefer that rather than getting it from gitorious?
[23:35] <llogan> J_Darnley: sorry, i was AFK. the latest sentence looks good to me. thanks.
[23:36] <llogan> what happens if a user tries -qscale and -qp?
[23:55] <J_Darnley> llogan: with my patch ffmpeg will print the message "-qscale is ignored with libx264, using -crf %0.0f instead." and then continue encoding using crf
[23:55] <J_Darnley> my patch only makes it print a warning
[00:00] --- Sat Mar 22 2014