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

[burek]

[00:02] <michaelni> i dont think encoders should ignore their input and that certainly cannot be encoded
[00:04] <michaelni> replacing Nans by silence or something else shouldnt be done in each encoder
[00:07] <cehoyos> The input was concatenated aac: Is it not valid to concatenate aac?
[00:39] <michaelni> the output from the decoder is not valid and cannot be encoded as such
[00:40] <cehoyos> So is there a bug in the decoder?
[00:40] <michaelni> maybe
[05:39] <jamrial> so all the filter-pixfmt failures when yuv2planeX_8 asm is enabled happen to be on 12 and 14 bits fmts, apparently because they are trying to run said 8bit function
[05:43] <jamrial> changing the "default:" into "case 8:" in that line fixes the failures with the funtion enabled
[07:40] <trio> exit
[11:02] <trio> Hello, I applied to FFmpeg for an internship through GNOME OPW. I wanted to say Hello.
[11:05] <trio> My qualification task was to restore daemon mode in FFserver. I would like to thank everyone who had been supportive to accomplish the task.
[11:09] <wm4> ?
[11:09] <wm4> how did this OPW thing end anyway
[11:10] <wm4> wasn't november 1st the deadline?
[12:06] <cone-912> ffmpeg.git 03Michael Niedermayer 07master:55d592f7d984: avcodec/aacdec: Skip processing channel elements which have not been present
[12:11] <michaelni> wm4, there where various deadlines for various things, the next thing to happen is that selected applicants will be posted by OPW on Nov 12 2014
[12:44] <cone-912> ffmpeg.git 03Michael Niedermayer 07master:d1970929b5f8: avformat/librtmp: fix swfurl
[16:44] <cone-619> ffmpeg.git 03Marton Balint 07master:631ac655c00e: ffplay: implement separete audio decoder thread
[16:44] <cone-619> ffmpeg.git 03Marton Balint 07master:cc4741888d7f: ffplay: fix indentation after last commit
[16:44] <cone-619> ffmpeg.git 03Marton Balint 07master:7ba727777587: ffplay: only output null packet once on EOF
[16:50] <cone-619> ffmpeg.git 03Marton Balint 07master:86476c510ebd: avfilter/avf_showwaves: fix off by one error in loop condition
[16:56] <cehoyos> kierank: Is the "Extended ancillary data syntax" part of the transport stream or part of the mpeg audio stream?
[16:56] <cehoyos> C.4.2 of http://www.etsi.org/deliver/etsi_ts/101100_101199/101154/01.11.01_60/ts_101154v011101p.pdf
[16:56] <kierank> in the mpeg audio bitstream
[16:57] <cehoyos> Do you know where in the libavcodec mp2 decoder I can find the data?
[16:57] <kierank> at the end of the frame i believe but I don't know if any encoders actually write it
[16:58] <cehoyos> So it is absolutely possible that it makes no sense to read it (because it isn't used)?
[16:58] <cehoyos> The reason I ask is that users asked for PLII decoding which MythTV supports but 
[16:58] <cehoyos> I wonder how to detect that two channel audio is PLII encoded.
[16:59] <kierank> you can't afaik
[16:59] <kierank> you just apply the matrix 
[16:59] <cehoyos> Except if the Extended ancillary data syntax is used you mean?
[17:00] <nevcairiel> i've never seen it actually used, i tried to identify such streams some time ago as well
[17:00] <nevcairiel> although when i read up about decoding PLII i gave up on that too, its annoying
[17:00] <cehoyos> nevcairiel: Does your software support PLII upmixing?
[17:00] <nevcairiel> no
[17:01] <nevcairiel> but people asked for it, but i just cba
[17:01] <cehoyos> MythTV source file el_processor.cpp contains a GPL implementation
[17:01] <nevcairiel> it requires fancy convolution filters which i didn't have the baseline code for
[17:02] <nevcairiel> encoding is so nice and easy, just a mixing matrix and done
[17:05] <cehoyos> Did you ever "test" the FFmpeg PLII necoder?
[17:05] <cehoyos> There is an unapplied patch that claims to fix a bug.
[17:05] <nevcairiel> it seemed to follow the spec when i looked at it
[17:06] <nevcairiel> i never tried to actually decode it again
[17:10] <cehoyos> I unfortunately cannot find the patch...
[17:10] <cehoyos> Only the ticket: https://trac.ffmpeg.org/ticket/3455
[17:14] <nevcairiel> thats how DPLII is supposed to be mixed, it doesn't sound perfect when you listen to it without decoding it again
[17:14] <nevcairiel> left gets the back channels subtracted, right gets them added
[17:14] <nevcairiel> so right is slightly louder
[17:38] <lukaszmluki> Is there a reason why AVCodecContext has no AVOptions for width and height?
[17:38] <lukaszmluki> Is there any problem I add it?
[17:40] <wm4> why would it need that ever?
[17:40] <wm4> aren't width and height either set by the decoder, or by the demuxer?
[17:40] <wm4> never the user
[17:42] <lukaszmluki> for encoding by the user
[17:42] <lukaszmluki> encoder will not encode when not set
[17:43] <wm4> even for encoding, the size is dictated by the input AVFrames, right?
[17:46] <lukaszmluki> look like it is respected what is set
[17:47] <cehoyos> I found the patch for PLII encoding: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/175700
[17:48] <cehoyos>  it doesn't sound perfect when you listen to it without decoding it again -> I think he meant it doesn't sound perfect after decoding it
[17:48] <cehoyos> Or maybe not...
[17:57] <cone-619> ffmpeg.git 03Lukasz Marek 07master:db2caf0a80d2: lavc/options: fix shallow copy context
[17:57] <cone-619> ffmpeg.git 03Lukasz Marek 07master:457204ee1592: lavu/opt: document av_opt_copy function
[17:57] <cone-619> ffmpeg.git 03Lukasz Marek 07master:4e179436b6c8: lavu/opt: copy dict in av_opt_copy
[18:06] <lukaszmluki> wm4: i checked and for example libx264 copy   AVCodecContext.width into  x264_param_t.i_width
[18:06] <lukaszmluki> and it produces frames with such dimensions
[18:06] <lukaszmluki> so my question is still opened 
[18:13] <cehoyos> Is your question how to set it? You only need a setter function for fields that do not exist in avconv, width and height are old fields.
[18:17] <lukaszmluki> I asked why they are have no corresponding AVOption to set them
[18:17] <lukaszmluki> and if I may add it
[18:18] <nevcairiel> why do you need avoptions for those, just set them directly
[18:26] <lukaszmluki> Hard to explain without a context, but such option would simplify some things I'm working on
[18:26] <lukaszmluki> but nevermind for now
[18:27] <lukaszmluki> for now setting manually is ok
[18:54] <jamrial> kierank: will you send an updated patch with the change i mentioned above?
[19:43] <cone-619> ffmpeg.git 03Carl Eugen Hoyos 07master:e971eef8c0d2: Set -scan_all_pmts 1 in ffmpeg, ffplay and ffprobe if not set by user.
[19:47] <kierank> jamrial: what change?
[19:47] <kierank> 4:39 AM <"jamrial> so all the filter-pixfmt failures when yuv2planeX_8 asm is enabled happen to be on 12 and 14 bits fmts, apparently because they are trying to run said 8bit function
[19:47] <kierank> ah
[19:47] <jamrial> default -> case 8
[19:58] <cehoyos> Should the fixes for ticket 3762 and ticket 4084 be backported to release branches?
[20:08] <cehoyos> nevcairiel: I don't remember if you are using the libavformat mpegts demuxer: The sample that you provided for tickets 2441 and 3762 (announced in 2186) needs "-scan_all_pmts 1": You may want to make this default.
[21:12] <kierank> jamrial: sent but i think it got stuck in the ml queue
[21:22] <jamrial> it just went through
[22:57] <kierank> michaelni: what is avoidable in the c api
[23:15] <michaelni> the data tables in the C API are structured for C, the SIMD API structures them for SIMD, filter coefficients already replicated and in the right format for SIMD consumption, also indexes to he source lines and end identifer are in there IIRC these reduce the number of needed registers as well as needed instructions
[23:18] <ubitux> is it normal that ffplay doesn't quit anymore with 'q'?
[23:21] <kierank> ubitux: see the ml
[23:22] <ubitux> i have the problem in 2.4 as well
[23:22] <kierank> michaelni: yes but the majority of yuv2yuvX functions are c api.
[23:22] <ubitux> kierank: what are you refering to?
[23:22] <kierank> can we just not add a check for bitexact and use that function
[23:22] <kierank> yuv2yuvX_8 takes up 33% of my cpu doing a 422 to 420 conversion
[23:23] <kierank> ubitux: ffplay thread discussion
[23:24] <ubitux> mmh ok
[23:24] <ubitux> thanks
[23:24] <kierank> and maybe bitexact should be default
[23:24] <kierank> it's not 1998 any more
[23:26] <michaelni> all the yuv2packedX functions are SIMD API its only the 2plane one which are not IIRC
[23:26] <michaelni> also we have existing asm for this
[23:27] <michaelni> thats actually why that patch fails
[23:27] <michaelni> the existing asm is overriden but the API switch is not
[23:28] <michaelni> please see c->yuv2planeX = RENAME(yuv2yuvX    ); and the yuv2yuvX_*
[23:28] <kierank> oh well I'll just have to patch swscale locally 
[23:28] <michaelni> enjoy 2x slowdown
[23:29] <jamrial> wouldn't setting use_mmx_vfilter to 0 if the yasm versions are used solve this?
[23:29] <kierank> michaelni: for the non-bitexact mode I don't use...
[23:29] <michaelni> jamrial, yes but you still get the 2x slowdown
[23:30] <michaelni> why do you want to replace fast asm by slow asm ???
[23:30] <kierank> do a yuv422p to yuv420p conversion and tell me that's fast...
[23:30] <kierank> when it uses yuv2yuvX_c
[23:31] <kierank> not to mention my hac^h^hpatches to stop pointless (x * 2^n) >> n in luma
[23:31] <michaelni> kierank, if you disable asm it is slow yes
[23:31] <kierank> no asm is not disabled
[23:31] <kierank> because of that commented out line it uses c
[23:31] <kierank> for me anyway
[23:32] <michaelni> kierank, if you disable bitexact then the optiized yuv2yuvX is disabled
[23:32] <kierank> I'm using bitexact
[23:32] <michaelni> but we can enable that C API function ofr bitexact that should be ok
[23:32] <michaelni> need to test
[00:00] --- Mon Nov 10 2014