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

burek burek021 at gmail.com
Wed Jun 25 02:05:02 CEST 2014


[01:08] <cone-622> ffmpeg.git 03Michael Niedermayer 07master:9326caa5faa1: avutil/lzo: allow selecting the compression function in the test code
[01:08] <cone-622> ffmpeg.git 03Tobias Rapp 07master:f6e772f9b5cf: ffprobe: add color_range and color_space to stream output
[01:19] <cone-622> ffmpeg.git 03Vittorio Giovara 07master:ab72eda15e98: pixfmt: mark the reserved values
[01:19] <cone-622> ffmpeg.git 03Michael Niedermayer 07master:faa1d4b1340f: Merge commit 'ab72eda15e98197cf148abc08574206cfde0d9b0'
[01:23] <BBB> jamrial: so & is it faster? (ssse3 emu edge)
[01:42] <jamrial> didn't bench it, but it should considering it's one mov + pshufb vs two movs, an imul and like two punpk* in most cases
[01:46] <cone-622> ffmpeg.git 03Vittorio Giovara 07master:10306e9c5fcc: jpeg2000: fix dereferencing invalid pointers during cleanup
[01:46] <cone-622> ffmpeg.git 03Michael Niedermayer 07master:97511bc7cf44: Merge commit '10306e9c5fcc28bd9310a9b38f21540e9e1433e9'
[02:05] <cone-622> ffmpeg.git 03Vittorio Giovara 07master:772d150a6e82: h264: error out from decode_nal_units() when AV_EF_EXPLODE is set
[02:05] <cone-622> ffmpeg.git 03Michael Niedermayer 07master:82e4340f1ef0: Merge commit '772d150a6e82542c06b0c251e73dd299d98d1027'
[02:05] <cone-622> ffmpeg.git 03Michael Niedermayer 07master:47048aa30b5c: avcodec/h264: do not leave ret random on minor failures, causing major failure
[02:06] <jamrial> BBB: http://pastebin.com/AerP440D this win64
[02:18] <ac_slater> hey guys. #ffmpeg is a little dead and I don't think I've ever received any responses to any libav* questions. I'm just looking for some general workflow documentation. What are contexts and when to use them? I guess just basic things. `doc/examples` doesnt have any networking/streaming code so I'm not sure and of the url_* functions work and how URLContext is maintained. Any help is much appreciated
[02:18] <ac_slater> and sorry for going offtopic
[02:19] <ac_slater> s/not sure/not sure how/g
[02:21] <cone-622> ffmpeg.git 03Michael Niedermayer 07master:eab2509f8ccf: avcodec/x86/h264_qpel_10bit: locally define pb_0
[02:23] <BBB> ac_slater: thats a very generic question, Im sure youre having a more specific problem?
[02:24] <BBB> if not, just start doing stuff? and report if you have problems?
[02:24] <BBB> network is typically done thoruhg opening a file with AVFormatContext btw
[02:25] <ac_slater> BBB: I guess my question was meant to be vague - but you're right, without a specific misunderstanding, no one can help. I guess the size of libav* is intimidating. I'll post to the mailing list of #ffmpeg with specifics and leave you guys alone ;). 
[02:44] <Compnn> ac_slater : theres some docs on http://wiki.multimedia.cx
[02:45] <Compnn> not sure how up to date they are
[02:45] <Compnn> but yeah libav-user list is best if developing 3rd party thing
[02:47] <ac_slater> Compnn: thanks mate. 
[03:17] <cone-622> ffmpeg.git 03Michael Niedermayer 07master:236aa4de2a10: avfilter/vf_hqx: avoid floats
[03:17] <cone-622> ffmpeg.git 03Michael Niedermayer 07master:723550d3cadb: avfilter/vf_hqx: optimize table init
[03:19] <michaelni> ubitux, just pushed some hqx float fix attempt, hope you didnt mind, but i hate leaving things broken
[04:52] <cone-622> ffmpeg.git 03Georg Lippitsch 07master:e3b03da77299: EBU Tech 3285 - Supplement 3 - Peak Envelope Chunk encoder
[04:52] <cone-622> ffmpeg.git 03Georg Lippitsch 07master:fd504f7c6fb8: Peak Envelope Chunk encoder: Indent
[05:13] Action: Compnn trolls carl some
[06:21] <ac_slater> alright I've been debating asking this. In the current decoding_encoding example, why isnt there a proper PTS set around line 444? Sending the output of `./decoding_encoding h264` to the `demuxing_decoding` shows NOPTS. Just curious mostly. 
[08:20] <ubitux> michaelni: no that's fine, i should have pushed the fix yesterday, thank you
[08:29] <mraulet> kierank: commits ff7926d5092f9d4158108963e977e8c992322ba4 and ff7926d5092f9d4158108963e977e8c992322ba4 from https://github.com/OpenHEVC/FFmpeg/commits/ffmpeg_patch help you?
[08:49] <kurosu> ah, seems to come and go
[08:49] <kurosu> I guess he just reacts to the irc logs
[08:49] <kurosu> mraulet: hi
[08:50] <kurosu> mraulet: in case you are reading the irc logs as I suspect, are you still allocating full frame structures for the data?
[08:51] <kurosu> except if you also use wpp, you really need only 2 lines of CTBs, and the compressed MV field for the next image
[08:51] <kurosu> it should reduce memory use
[08:52] <kurosu> but the biggest drawback will be the amount of painfully debugged changes
[08:53] <plepere> good morning. :)
[10:07] <BtbN> QSV on linux requires that you buy a 500$ Intel SDK...
[10:07] <BtbN> And the encode api in vaapi is... not great.
[10:45] <kierank> mraulet: yes :)
[11:41] <mraulet> michaelni: ff7926d5092f9d4158108963e977e8c992322ba4 and 39c4d45c7788081c45c7fae51b7c5d0bcbaece9d from openhevc/ffmpeg will greatly reduce pps computation (useful for streaming application)
[11:42] <kierank> Useful for watching world cup in 4k :)
[11:43] <mraulet> you can use our ffmpeg flavor then :)
[11:43] <mraulet> ^^
[11:44] <kierank> Yeah
[11:48] <mraulet> bitrates for the world cup?
[12:11] <kierank> mraulet: 36mbps
[12:11] <kierank> www.bbc.co.uk/rd/blog/2014/06/bbc-r-d-ultra-high-definition-trials
[12:19] <mraulet> 10bit?
[12:25] <kierank> 8-bit
[12:25] <kierank> mraulet: obe.tv/about-us/obe-blog/item/12-first-look-at-bbc
[12:28] <mraulet> kierank: thanks
[12:35] <kierank> av500: 
[12:35] <kierank> person:         Vladimir Pantelic
[12:35] <kierank> address:        Archos Deutschland GmbH
[12:35] <kierank> who's this guy
[13:20] <kriegerod> is there a function in libavutil to read all the content of file descriptor to a memory buffer? if not, i'm going to make one
[13:22] <kierank> fread?
[13:22] <kriegerod> that's to read once, i have a need to read out to EOF
[13:23] <thardin> fread the size of the buffer, check how much you actually got?
[13:23] <kriegerod> libavdevice/lavfi.c dumps '-graph_file' argument with help of av_file_map(), which fails on /dev/stdin, which i want to use for that
[13:24] <kriegerod> thardin: no guarantee to read up to EOF with one call
[13:24] <J_Darnley> I asked about this recently...
[13:24] <thardin> you want to read a filter frmo a pipe?
[13:25] <kriegerod> from stdin
[13:25] <BBB> glib has functions for that
[13:25] <BBB> why do you specifically need that function in libavutil?
[13:25] <BBB> (or java)
[13:25] <thardin> and you can use -graph_file <(your_command_here)  ?
[13:25] <thardin> *can't
[13:25] <J_Darnley> There's an av_* function, something like mmap
[13:25] <kriegerod> thardin: yes
[13:25] <thardin> schtrange
[13:26] <kriegerod> J_Darnley: av_file_map(). fails on /dev/stdin by design, and it cannot fallback to usual reading
[13:26] <kriegerod> so now i'm making a fallback mechanism in lavd/lavfi.c
[13:26] <J_Darnley> oh, well
[13:26] <kriegerod> willing either to not reinvent it if it is already there, or to move this code to lavu
[13:27] <thardin> or wait, fread is designed to be buffered and all that. why would it not read until EOF if the element size is 1?
[13:28] <thardin> (ignoring possible slowness, not sure if it's smart enough to not read byte-by-byte)
[13:28] <J_Darnley> Other than that I think I was pointed to lut3d and/or curves that just uses fread on an entire file.
[13:28] <kriegerod> thardin: even if this approach worked, what buffer size should we preallocate? 1 MB? delicate question
[13:28] <thardin> well, then you just have the same problem again don't you?
[13:29] <cone-96> ffmpeg.git 03gcocherel 07master:f7f1f4c7ce9c: avcodec/hevc_ps: remove min_cb_addr_zs
[13:29] <cone-96> ffmpeg.git 03gcocherel 07master:ba70563d5549: hevc/pps: optimized size of min_tb_addr_zs reduce computation too (cherry picked from commit 39c4d45c7788081c45c7fae51b7c5d0bcbaece9d)
[13:29] <michaelni> mraulet, kierank cherry picked the 2 comits
[13:29] <kierank> thanks
[13:30] <kriegerod> thardin: i have checked vf_curves and vf_lut3d, they don't do exactly what you've said
[13:31] <thardin> ok
[13:32] <thardin> well, someone's probably already written a "read fd into dynalloc'd buffer" function, as BBB hinted
[13:34] <J_Darnley> I've got one but it won't work if you can't seek
[13:34] <J_Darnley> Actually I think I stole it from x264
[13:34] <kriegerod> thardin: no, in lut3d i see consequential fread()s and parsing
[13:34] <kriegerod> in vf_curves i haven't seen anything related to open/read
[13:35] <kriegerod> J_Darnley: yes i have seen something checking buffer size using fseek+ftell
[13:35] <kriegerod> so likely there's no such thing at the moment, proceeding with my code, will submit soon
[13:36] <J_Darnley> vf_curves use av_file_map
[13:36] <J_Darnley> (line 329 if you're interested)
[13:37] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:2e1e10a6bb7d: avformat/wavenc: use the bitexact flag from avformat instead of the one from avcodec
[13:37] <J_Darnley> I look forward to seeing what you propose
[13:47] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:d34d3304a8b7: avformat/wavenc: do not hardcode array size in memset and other functions
[13:59] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:3bd0221bc1a0: avformat/wavenc: more specific error return for "Writing 16 bit peak for 8 bit audio"
[13:59] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:501158c682ce: avformat/wavenc: simplify malloc failure checking
[15:31] <kriegerod> J_Darnley: i have posted my patches in maillist, see author Andrey Utkin
[15:42] <J_Darnley> Your documentation about the function is good.
[16:26] <J_Darnley> I wonder if that bug report is really because he hasn't used enough?
[16:28] <J_Darnley> or maybe not.
[16:49] <kierank> plepere: http://obe.tv/about-us/obe-blog/item/13-a-look-at-the-hevc-encoder-bbc-uhd-world-cup-part-2
[16:49] <kierank> it's not one of fionag's legendary tearaparts
[16:49] <kierank> but it should deal with a lot of things
[16:50] <plepere> I'm battling my avx2 function, but I'l read that ASAP.
[18:41] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:74bd039f8cc2: avformat/nutdec: improve probe speed by 30%
[19:42] <michaelni> mateo`, thardin, any other mxf people around, is " Gaullier Nicola (3.8K) [FFmpeg-devel] [PATCH] set/force channelcount in MXF D-10" ok ?
[19:44] <mateo`> michaelni: i'm having a quick look at it, i've faced this same bullshit by the past :)
[19:58] <michaelni> mateo`, thx
[20:00] <mateo`> haha funny, it comes from smartjog :)
[20:04] <kierank> mateo`: is smartjog now arkena?
[20:04] <kierank> "Cognacq-Jay Image, PSN, Qbrick and SmartJog announce today that they regroup all their activities under a single company and a new brand, Arkena. Arkena"
[20:04] <kierank> apparently so
[20:09] <mateo`> kierank: yes
[20:25] <mateo`> michaelni: review done
[20:36] <keynote2k> Hello, all.  I'm Software Freedom Conservancy's General Counsel.  In the process of investigating a GPL violation report on behalf of one of our member projects, we discovered a possible GPL violation relating to ffmpeg.  I'd like to submit a violation report; where should I send it?  
[20:37] <keynote2k> e.g., does FFmpeg have a dedicated email address for receiving and processing GPL violation reports?
[20:39] <j-b> lol
[20:40] <j-b> "possible GPL violation relating to ffmpeg"
[20:40] <j-b> You mean, the 10000s violation, right?
[20:41] <keynote2k> sigh, that wouldn't surprise me.  :)
[20:42] <J_Darnley> I don't know about a dedicated email address but there is a category for it on trac.
[20:42] <michaelni> mateo`, thx
[20:43] <iive> we used to have a lawyer that was actively negotiation settlements.
[20:43] <iive> unfortunately after the fork the whole thing went down the drain.
[20:44] <keynote2k> J_Darnley:  thx.   Is there a particular tag that you recommend?  
[20:44] <keynote2k> iive:  sorry to hear that.  
[20:44] <kierank> keynote2k: gpl violation from whom
[20:45] <iive> also, the primary license of ffmpeg is lgpl. 
[20:45] <nevcairiel> well it really depends how its build, its a GPL violation if they use a GPL build
[20:45] <J_Darnley> keynote2k: not off hand but I can go look
[20:46] <keynote2k> kierank:  I'd rather not say on IRC.  Conservancy's policy is to file a report privately, and let the project determine whether to make the report public or not.  
[20:46] <iive> yes, it have to be checked what options are used for the build. and afaik linking to gpl library makes the whole thing gpl (e.g. x264)
[20:46] <keynote2k> But, if there's no other way to file a report, we are willing to submit a report to a publicly-archived mailing list, if necessary
[20:47] <iive> i think there was ffmpeg-legal maillist, not sure if it is still active.
[20:47] <kierank> it's gone afaik
[20:48] <iive> maybe michaelni could be of more help...
[20:48] <keynote2k> iive, nevcairiel:  our analysis is currently focused on the use of our member projects' code, so I don't know if our compliance engineer's analysis went to the level of determining whether FFmpeg's optional GPL'ed components were included in the build.  
[20:49] <J_Darnley> keynote2k: I meant using the "Type" category with "license violation" on trac but I should say that is public though.
[20:49] <iive> i assume that ffmpeg libraries are used, not the whole ffmpeg.
[20:49] <keynote2k> (which is another reason why I'd prefer to submit the report privately to the right channels, as opposed to making a public accusation of a license violation)
[20:49] <iive> ffmpeg application.
[20:50] <michaelni> ffmpeg-legal ML was deleted because it was unused for years
[20:51] <michaelni> see " [FFmpeg-devel] [RFC] deleting ffmpeg-legal mailing list"
[20:53] <keynote2k> well, if there isn't a dedicated email address, then it sounds as if ffmpeg-trac is the only viable option.  I'll check back in with our compliance team to determine how to best proceed with submitting the report.
[20:53] <keynote2k> Thank you for your responses.  :)
[21:41] <cone-96> ffmpeg.git 03Derek Buitenhuis 07master:c11043aca736: mjpegdec: Properly set the context colorspace info
[21:52] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:0ed110133f77: avfilter/vf_colormatrix: fix macro ()
[21:52] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:f364101144f1: avfilter/vf_deshake: fix macro ()
[22:25] <cone-96> ffmpeg.git 03Derek Buitenhuis 07master:2deb614272e6: mjpegdec: Properly set the context colorspace info
[22:25] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:50daffead2de: Merge commit '2deb614272e6faad8802c5341971d08c7272f74d'
[22:41] <cone-96> ffmpeg.git 03Marton Balint 07master:9dd97aa3d337: ffplay: eliminate pictq_prev_picture
[22:41] <cone-96> ffmpeg.git 03Marton Balint 07master:ba800defa7c8: ffplay: pass simple integers to calculate_display_rect and set_default_window_size
[22:41] <cone-96> ffmpeg.git 03Marton Balint 07master:1ca5c1784b1d: ffplay: calculate SDL audio buffer size based on sample rate
[22:41] <cone-96> ffmpeg.git 03Marton Balint 07master:371f02388cb1: ffplay: decrease max audio callbacks per second
[22:41] <cone-96> ffmpeg.git 03Marton Balint 07master:e281671e21d3: ffplay: decrease audio_diff_threshold
[22:41] <cone-96> ffmpeg.git 03Michael Niedermayer 07master:0f59bba9cb95: Merge remote-tracking branch 'cus/stable'
[23:30] <Timothy_Gu> plepere: why are there four extra blank lines at the end of x86/hevcdsp.h?
[23:31] <Timothy_Gu> plus some more in your AVX2 patch
[00:00] --- Wed Jun 25 2014


More information about the Ffmpeg-devel-irc mailing list