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

burek burek021 at gmail.com
Wed Feb 5 02:05:02 CET 2014


[00:03] <michaelni> thardin, ok if i remove that "TBA, possibly " ? i just added this to all i copied from last year 
[00:03] <michaelni> as i didnt know if they are again available this year
[00:10] <michaelni> where did cone go ?
[00:12] <michaelni> did the netsplits take her to a parallel plane of existence and she is now lonely announcing commits in empty space ?
[04:50] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:8a3b85f3a795: avcodec/h264: update current_sps & sps->new only after the whole slice header decoder and init code finished
[05:03] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:10238ada6dac: cmdutils: update year
[05:03] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:e04f68f7c522: dnxhdenc: fix mb_rc size
[05:04] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:7adf4a92a17d: avcodec/vmnc: Check  that rectangles are within the picture
[05:04] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:74821341b9ac: avcodec/takdec: always check bits_per_raw_sample
[05:04] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:af74599e66b1: avcodec/vc1: reset fcm/field_mode in non advanced header parsing
[05:07] <michaelni> thardin, i just tried avplay, its stuck after 4sec as well
[05:34] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:e38c62fe0c24: lavf: simplify handling of offset in av_probe_input_buffer()
[05:34] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:539d255871c9: lavf: use a fixed width type
[05:35] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:8575f5362f98: lavf: make av_probe_input_buffer more robust
[05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:c06f8bac204a: avformat/utils: fix av_probe_input_buffer2() so it returns the probe score
[05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:35bf91c5b55b: Merge commit '8575f5362f98c937758b20ff8512d6767a56208e' into release/1.1
[05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:82b44665e982: avformat/utils/av_probe_input_buffer2: Fix pd.buf_size
[05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:3994eebb1e87: avformat/utils/av_probe_input_buffer2: fix offset check
[05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:ee3ce73bfb29: avformat/utils/av_probe_input_buffer2: fix buffer passed to ffio_rewind_with_probe_data()
[05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:a5c3f596d1f7: avformat/utils: av_probe_input_buffer2 decrease difference to libav
[05:58] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:af9799790d7a: dsputil/pngdsp: fix signed/unsigned type in end comparison
[05:58] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:10d48fe6d396: flashsv: Check diff_start diff_height values
[05:58] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:f1476459b701: vmnc: K&R formatting cosmetics
[05:58] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:fd856693defa: Merge commit 'f1476459b7013d306eb911573f1dc81e74ccd082' into release/1.1
[06:11] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:9f9e773881cf: vmnc: Port to bytestream2
[06:11] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:4b24eb1a03f2: vmnc: Check the cursor dimensions
[06:11] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:3485a07977f1: avi: DV in AVI must be considered single stream
[06:11] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:c85e5f13f6ac: cavs: Check for negative cbp
[06:11] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:9ac7d8f85d71: Merge commit 'c85e5f13f6ac9c4c90125e7671d89009e57f9df9' into release/1.1
[06:32] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:969028870c6f: cavsdec: check ff_get_buffer() return value
[06:32] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:d9c82cea11ce: h263: Check init_get_bits return value
[06:32] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:b5275ca1a805: h264_cavlc: check the size of the intra PCM data.
[06:32] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:f728782c0d30: segafilm: fix leaks if reading the header fails
[06:32] <cone-703> ffmpeg.git 03Martin Storsjö 07release/1.1:44079902c49e: mov: Free intermediate arrays in the normal cleanup function
[06:32] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:e2781db62a40: Merge commit '44079902c49e526f464bb4eb855665e1af867e91' into release/1.1
[06:39] <cone-703> ffmpeg.git 03Martin Storsjö 07release/1.1:a1b4d42d31ba: mov: Free an earlier allocated array if allocating a new one
[06:39] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:62ed6da016b7: h264: check that an IDR NAL only contains I slices
[06:39] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:cb8180885f22: Merge commit '62ed6da016b789eee00e0fff517df4a254e12e5d' into release/1.1
[07:05] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:299c5dcfb0cd: h264: reset num_reorder_frames if it is invalid
[07:05] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:3cc8d9bc1ffc: vc1: Always reset numref when parsing a new frame header.
[07:05] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:03bfd8419fba: mathematics: remove asserts from av_rescale_rnd()
[07:05] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:bf7c240a50f8: oggparseogm: check timing variables
[07:05] <cone-703> ffmpeg.git 03Reinhard Tartler 07release/1.1:27f60e2b0b41: Update Changelog for 9.11
[07:05] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:08dde7567dea: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[07:23] <ubitux> BBB: yes?
[08:14] <thardin> michaelni: huh. strange
[08:14] <thardin> but at least it's something to fix :)
[11:57] <ubitux> BBB: i have a fast 44_16 working for vert, and i need to make a faster transpose for the horizontal one
[11:57] <ubitux> i'll submit in a day or two i guess
[12:20] <Keestu_> when i play h264 video with ffplay 0.11 and ffplay 2.0, i see significant difference, but same in 800*640, are there any changes gone after 0.11 version specifically for H264?
[12:25] <nevcairiel> define difference
[12:28] <ubitux> between 0.11 and 2.0: 3260 files changed, 312860 insertions(+), 159965 deletions(-)
[12:29] <pross-au> thats like 1/3rd of the codebase
[12:30] <nevcairiel> 0.11 is pretty old
[12:30] <ubitux> 2.0 is as well btw
[12:31] <ubitux> BBB: actually, i probably can't do anything about the transpose since i need 8 lines for 44 as well...
[12:31] <ubitux> so i'll submit tonight
[12:33] <Keestu_> nevcairiel,  difference in terms of handling h264 format.  :)
[12:33] <nevcairiel> no, what differences do you see
[12:33] <Keestu_> i am trying to port ffmpeg into android,  hence  asking. 
[12:34] <ubitux> BBB: overall time goes from 3.90s to 3.78s
[12:34] <Keestu_> nevcairiel,  ok, while i  tried with ffplay in both the versions,  in the new version,  the video clarity is perfect, where as it is not in 0.11
[12:34] <ubitux> (ped1080p.webm)
[12:34] <Keestu_> but if i play  800*640 video both the versions has no difference. 
[12:35] <Keestu_> sorry it is *2.1
[12:35] <Keestu_> :)
[13:03] <BBB> ubitux: output transpose vs input transpose
[13:04] <BBB> ubitux: same as for h_88 (where you don't need a 16x8, just a 8x8 for the output, and then use movq/movhps x8 instead of movqx16 to move back to memory)
[13:04] <BBB> ubitux: so here you can do a fast 4x4 transpose that outputs to memory
[13:04] <BBB> errr I mean output the result of that in chnks to memory
[13:05] <BBB> (see vp8 also)
[13:24] <BBB> ubitux: and yes input would still be a full 16x8, I guess that sucks but nothing you can do
[13:25] <ubitux> indeed i can probably simplify the out transpose
[13:25] <ubitux> especially given that i probably have some of the values in registers already
[13:52] <cone-703> ffmpeg.git 03Anton Khirnov 07master:b25e84b7399b: hevc: check that the VCL NAL types are the same for all slice segments of a frame
[13:52] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:a0d5204cd990: Merge commit 'b25e84b7399bd91605596b67d761d3464dbe8a6e'
[14:11] <ubitux> http://pastie.org/8697703 seems like libav decided to remove some cosmetics now (jvdec.c)
[14:11] <ubitux> spaces shuffling \o/
[14:15] <Compn> abandon prettyprinting ?
[14:15] <ubitux> i guess it's just recursive cosmetics
[14:37] <nevcairiel> its funny when they do that
[14:41] <kierank> it's annoying because it makes stuff hard to merge
[14:41] <kierank> in both directions
[15:08] <cone-703> ffmpeg.git 03Keith Lawson 07master:de203abd71ba: vf_overlay: add eof_action switch
[15:08] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:905cd28a5a0b: Merge commit 'de203abd71baae7f120313259b45cf935c85203e'
[15:08] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:cddbe9fa2eb5: avfilter/dualinput: fix repeatlast to match docs and eof_action=pass
[15:15] <cone-703> ffmpeg.git 03Jan Ekström 07master:5de64bb34d68: utvideoenc: Add support for the new BT.709 FourCCs for YCbCr
[15:15] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:40fc1e2dda7b: Merge commit '5de64bb34d68d6c224dca90003172d7a27958825'
[15:23] <cone-703> ffmpeg.git 03Anton Khirnov 07master:7b03b65bf0d0: lavf: do basic sanity checking on muxed packets
[15:23] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:5144d919964f: Merge commit '7b03b65bf0d02519c86750d2da33f413e11cf0c6'
[16:07] <cone-703> ffmpeg.git 03Anton Khirnov 07master:33c859c142ef: lavf: ignore attachment streams for interleaving purposes
[16:07] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:073e771c9c53: Merge commit '33c859c142ef3f49b7a6227014ad92a680cf4d74'
[16:07] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:c18cfd1001e0: ffserver: use avformat_alloc_context()
[16:26] <cone-703> ffmpeg.git 03Anton Khirnov 07master:e46ad30a8087: vp8: use a fixed-size edge emu buffer
[16:26] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:9a082fec1af5: Merge commit 'e46ad30a808744ddf3855567e162292a4eaabac7'
[16:29] <ubitux> BBB: ok so i got a simpler transform
[16:30] <ubitux> anyway, overall, it's not that much faster
[16:30] <ubitux> do you want me to start looking at the _8 variants now?
[16:53] <ubitux> mmh found a way to simplify some code
[17:16] <cone-703> ffmpeg.git 03Anton Khirnov 07master:1f097d168d9c: h264: reset data partitioning at the beginning of each decode call
[17:16] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:c93e69136925: Merge commit '1f097d168d9cad473dd44010a337c1413a9cd198'
[17:16] <ubitux> yay, saved about 6 instructions
[17:23] <ubitux> http://pastie.org/pastes/8698325/text
[17:24] <nevcairiel> you should optimize that function on the top there
[17:25] <ubitux> probably yes :p
[17:26] <ubitux> i'm start lacking motivation for doing the remaining _8 variants of lpf
[17:26] <ubitux> -'m
[18:08] <relaxed> https://trac.ffmpeg.org/ seems to be down
[18:21] <Compn> relaxed : server maint
[18:25] <Daemon404> Compn, usually you would put up a page saying that
[18:25] <Daemon404> instead of jst timing out
[18:25] <nevcairiel> maybe the whole server is in maint
[18:26] <nevcairiel> its a bit crazy to redirect dns for a few hours of maintenance =P
[18:26] <Daemon404> usually they put a notice for the preceding few hours/days too
[18:26] <Daemon404> warning of it
[18:26] <Daemon404> ;)
[18:26] <nevcairiel> maybe it was there!?!?
[18:26] <nevcairiel> :D
[18:27] <Compn> the whole server is down, correct
[18:27] <Daemon404> rm -rf /
[18:28] <Daemon404> woops
[18:28] <Daemon404> server maitenence time
[18:28] <nevcairiel> thats an impossible command on any recent linux
[18:28] <Compn> i blame ubuntu
[18:33] <Daemon404> nevcairiel, eh
[18:34] <Daemon404> just 1.5 yers ago i did it on ubuntu
[18:34] <Daemon404> must be pretty recent
[18:34] <Daemon404> or well, i did: rm -rf dir /*
[18:35] <nevcairiel> i just know that the plain rm -rf / requires an extra parameter to eb passed to work
[18:35] <nevcairiel> not sure since when
[18:35] <nevcairiel> but ubuntu isnt known for cutting edge versions of things
[18:35] <Daemon404> lol
[18:35] <Daemon404> since then ive stopped using bash
[18:35] <Daemon404> i use zsh fulltime
[18:36] <nevcairiel> rm is a builtin in zsh?
[18:36] <Daemon404> no?
[18:36] <nevcairiel> then why does it matter?
[18:36] <Daemon404> it can check commands for stupidity before running them
[18:36] <Daemon404> in nteractive mode
[19:07] <ubitux> BBB: https://github.com/ubitux/FFmpeg/compare/vp9-simd
[19:41] <llogan> Daemon404: don't feel bad. one user destroyed /var on a work server. he was trying out magento which smartly uses the name "var" for a directory, AFAIK.
[19:41] <Daemon404> llogan, luckily this was just my personal workstation
[19:41] <Daemon404> i just reinstalled the OS and sync'd my dot files
[19:41] <Daemon404> it sure was a waste of time though
[19:42] <llogan> yeah. this was before I had daily images.
[20:38] <kierank> thardin: Aside: can we just use libmxf instead? Or would that cause problems? I
[20:38] <kierank> know NIH runs deep in this project, 
[20:38] <kierank> lol
[20:38] <kierank> opening a can of worms here
[20:42] <Daemon404> kierank, do you think it i possible for a 3rd party (us) to independently implement mxf?
[20:42] <Daemon404> i dont.
[20:42] <Daemon404> because mxf.
[20:43] <nevcairiel> isnt ffmpeg kinda a third party that implemented mxf independently?
[20:43] <Daemon404> and it doesnt work a lot :P
[20:43] <nevcairiel> i have no idea
[20:43] <nevcairiel> i just got people complain to me once that they want to play mxf audio, and i only allow playing one stream
[20:43] <nevcairiel> (while apparently mxf audio comes one channel in one stream or something)
[20:46] <thardin> kierank: I am well aware :)
[20:46] <kierank> I personally don't think there is anyone in the world who knows mxf better than the author of libmxf
[20:47] <thardin> but I'm more worried about mxfenc producing crap files that need to be supported in future versions
[20:47] <thardin> forever
[20:48] <thardin> yeah. bbc is pretty safe bet
[21:08] <kierank> libmxf is the ultimate troll tool
[21:08] <kierank> since it's the reference implementation for mxf file delivery in the uk
[21:08] <kierank> useful for proving people's shit is broken
[21:20] <thardin> nice
[21:20] <thardin> mxfdump and mxfsplit are also useful
[21:22] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:41f974205317: avcodec/vc1dec: vc1_pred_b_mv() is not used for fields, simplify code
[21:22] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:20be510887d0: avcodec/vc1dec: remove blocks_off use from vc1_pred_b_mv()
[21:23] <kierank> thardin: many vendors are starting to attack open source
[21:23] <kierank> so I have started a fightback
[21:25] <kierank> they get angry when i prove their stuff is broken as Daemon404 saw
[21:26] <ubitux> mxf generated with ffmpeg are libmix-compliant?
[21:26] <ubitux> s/mix/mxf/
[21:27] <thardin> kierank: yeah, I've done similar things
[21:28] <thardin> I suspect mxf is designed to create billable hours
[21:42] <j-b> kierank: what is it?
[21:42] <j-b> libmxf?
[21:45] <kierank> yes
[21:45] <kierank> j-b:  thardin has suggested adding libmxf support to ffmpeg
[21:46] <JEEB> sounds like a good idea
[21:46] <JEEB> mxf is something that you might not want to divide resources on
[21:47] <j-b> kierank: the BBC thing?
[21:47] <kierank> Yeah
[22:05] <saste> anybody going to mentor gsoc projects?
[22:09] <llogan> Mentoring organization application deadline is Feb 14, so we have ~10 days.
[22:12] <j-b> good luck
[22:14] <llogan> j-b: we decided to give it a try, but personally i'm not expecting anything different from Google.
[22:18] <j-b> llogan: good idea.
[22:18] <j-b> please add DTS-HD decoder to the list
[22:20] <saste> llogan, anyway any available mentor?
[22:20] <saste> and, trac is down
[22:25] <llogan> saste: i'm not sure of the status of trac, or who wants to mentor other than michael, paul, and maybe thomas.
[22:27] <llogan> j-b: will copying this suffice? http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013#DTS_.2F_DCA_Improvements
[22:27] <michaelni> llogan, saste ill probably put the gsoc wiki page onto wiki.multimedia.cx just trying to finish merging the formatting back in
[22:27] <j-b> llogan: yes
[22:27] <llogan> michaelni: why? due to trac being down lately?
[22:28] <llogan> j-b: ok, i'll add it. would you like to mentor it?
[22:28] <michaelni> because multimedia.cx seems more stable ATM than trac.ffmpeg.org
[22:28] <michaelni> also we lost some formating when we copied it from archive.org
[22:29] <llogan> what's the deal with trac today?
[22:30] <michaelni> will write news entry about it but i need to work on gsoc wiki 
[22:30] <michaelni> now
[22:31] <llogan> i don't like having to rely on a third party wiki, but i guess if trac is being shitty...
[22:31] <michaelni> gsoc doesnt wait ... sadly
[22:32] <ubitux> :(
[22:32] <ubitux> i guess that gives me some delay before editing it
[22:32] <llogan> is libaby applying too?
[22:33] <JEEB> <facugaich> Hi, I was wondering if you guys have any plans for GSoC 2014
[22:33] <JEEB> <Keiler> probably not entering
[22:33] <JEEB> <Keiler> Google has WebM after all
[22:33] <JEEB> from #libav-devel
[22:33] <llogan> ah. he asked in #ffmpeg too.
[22:33] <llogan> "facugaich | llogan: Well... I was planning on doing it as a CS project, so I was looking for something with a little bit of academic interest"
[22:34] <llogan> i told him to come here if he has additional questions, etc
[22:35] <JEEB> he seemed to have asked around
[22:35] <JEEB> he was in #videolan too
[00:00] --- Wed Feb  5 2014


More information about the Ffmpeg-devel-irc mailing list