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

[burek]

[01:37] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:7c98c834e0a2: avformat/avidec: also print position in print_tag()
[01:37] <cone-670> ffmpeg.git 03gcocherel 07master:36658c978f5d: hevc : update hevc_ps.c
[01:37] <cone-670> ffmpeg.git 03gcocherel 07master:fb7d70c1cd95: hevc : add hevc profile
[02:36] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:9cbe834dfd49: avformat/avidec: Skip duplicate strf chunks
[09:08] <plepere> is there something to do for my asm to be able to compile for 32bit ?
[09:09] <plepere> bacause when I try cross compiling, I get errors that my registers are 64-bit
[09:12] <nevcairiel> do you use the q postfix?
[09:13] <plepere> it doesn't ring a bell, so I guess not
[09:13] <plepere> what is it ?
[09:13] <nevcairiel> like r9q
[09:13] <plepere> oh
[09:13] <nevcairiel> because no quadword registers on 32-bit
[09:13] <plepere> ok
[09:14] <plepere> so I should replace all rX by rXq ?
[09:14] <nevcairiel> no, you should not use q :)
[09:14] <plepere> ok
[09:14] <nevcairiel> also, 32-bit might not have enough registers
[09:15] <wcpan_> hi, how could I 'discard' an AVPacket ?
[09:16] <nevcairiel> you only get up to r6 on 32-bit, iirc
[09:16] <plepere> well I do have a undefined symbol `r7' (first use) error. But I doubt that there are less than 8 registers
[09:16] <plepere> ouch
[09:16] <nevcairiel> 7 registers, plus the stack pointer
[09:16] <plepere> how do I use my arguments then ?
[09:16] <nevcairiel> from the stack
[09:16] <plepere> ok
[09:17] <nevcairiel> how many arguments does that function have?
[09:17] <plepere> 9
[09:17] <wcpan_> i found that if i don't do avcodec_decode_* after av_read_frame, i'll receive like 'reference frame missing' error log
[09:17] <nevcairiel> and you need to access all arguments in the asm?
[09:18] <plepere> eventually, yes
[09:18] <plepere> but for a simple case, I can need only use the first 6
[09:19] <nevcairiel> might need to get smart about the parameter usage then, and load them from the stack only when needed to save registers
[09:20] <nevcairiel> sadly i'm not that experienced with such stack optimizations either
[09:20] <plepere> ok
[09:22] <plepere> but how do I put the arguments in the stack ?
[09:23] <plepere> since cglobal puts the arguments in registers
[09:24] <nevcairiel> all arguments are on the stack by default, cglobal only puts them in registers if you tell it to, so just tell it that you have less arguments then you really do, and it wont touch them, and you can do it manually
[09:24] <plepere> ok
[09:26] <plepere> so just to make sure : to access the arguments, I can only push/pop.
[09:27] <nevcairiel> you should probably access the parameters directly via memory address, and not push/pop them
[09:27] <nevcairiel> i believe the asm macros have some helpers for that
[09:27] <nevcairiel> but i forgot how that worked
[09:27] <plepere> ok, I'll dig in the x86util then
[09:30] <plepere> thank you
[09:31] <ubitux> mmh i'm using "strideq", "dstq", ... does that mean it won't work on 32?
[09:31] <ubitux> (it seems to, so far)
[09:32] <nevcairiel> maybe its smart and maps the q to native size
[09:32] <nevcairiel> i dunno
[09:49] <ubitux> michaelni: about the incoming doc examples build patchset from Diego, i'm assuming we can merge it; it will allow building them within FATE; though the Makefile should be kept as well as a demonstration for how to build them when using packages
[09:49] <ubitux> (the Makefile = the one in doc/examples)
[09:50] <ubitux> i'll update the examples/README when it's done
[09:55] <clever> ubitux: got any time to help with my 264 issues?
[09:55] <ubitux> i can try, but you know, i'm not familiar with what you are doing
[09:55] <ubitux> but sure go ahead, ask the channel
[09:55] <clever> the issue, is that ffmpeg is removing a header from the start of the h264 stream
[09:56] <clever> i have managed to exract it from one file: http://pastebin.com/7LyarVYy
[09:56] <clever> but the size of the header is different in each file, and the contents differ
[09:56] <clever> so i'm not sure how to modify ffmpeg to give that header on demand
[09:57] <ubitux> how large was the extradata already?
[09:57] <clever> and until i can figure out what the data in it means, i cant easily see if the chunks of data i'm finding are valid
[09:57] <clever> about 60 bytes
[09:57] <ubitux> doesn't it contain the top content (and all the x264 encode comment is stripped)?
[09:57] <clever> and inserting that at the start just gave a blank screen
[09:57] <ubitux> did you compare the data? is the the same or unrelated?
[09:57] <clever> it has some similar binary codes, but parts of it differ
[09:57] <clever> several of the first bytes are different
[09:58] <ubitux> what's your format?
[09:58] <clever> let me put av_hex_dump back on
[09:58] <clever> my format?
[09:58] <ubitux> the container
[09:58] <ubitux> mov/mp4? mts?
[09:58] <clever> mkv
[09:58] <clever> ubitux: http://www.auby.no/files/video_tests/h264_1080p_hp_4.1_40mbps_birds.mkv this file to be exact
[09:58] <clever> thats where the header in the pastebin came from
[09:59] <clever> if i hard-code ffmpeg to inject that header from a file, it works perfectly
[09:59] <clever> but if i use extradata, i just get a black image
[10:00] <clever> ubitux: http://pastebin.com/6XSvLrM3 this has the extradata bytes
[10:01] <ubitux> add 0x00 0x00 at the beginning :-°
[10:01] <clever> *tries*
[10:01] <nevcairiel> that wont work
[10:01] <nevcairiel> mkv uses different start codes
[10:01] <ubitux> oh erm
[10:02] <nevcairiel> mkv extradata usually has a 2 byte length code before every NAL
[10:02] <nevcairiel> well in fact, mkv extradata is its own special format
[10:02] <JEEB> matroska uses AVCc pretty much
[10:02] <nevcairiel> the same as mp4 h264 extradata
[10:02] <JEEB> yup
[10:02] <clever> nevcairiel: looking at my last pastebin, lines 2 and 7, which one looks like mkv mangling?
[10:03] <nevcairiel> there is no mangling
[10:03] <nevcairiel> thats just how it works
[10:03] <clever> why does the header start with 0x0000 then?
[10:03] <clever> the 2 byte lenght code is 0 ??
[10:03] <nevcairiel> because mkv is different then raw video streams
[10:03] <JEEB> grab a copy of 14496-15 for details :P
[10:03] <clever> the omx decoder seems to function better with the raw video streams
[10:04] <clever> JEEB: yeah, thats kinda what i need, to make sense of this binary souo
[10:04] <clever> soup*
[10:04] <nevcairiel> the 0x00000001 start code is replaced by a length code 
[10:04] <JEEB> matroska uses the same extradata as 14496-15 and the same idea of having length + contents of NAL in a packet
[10:04] <JEEB> the length field's size is set in the extradata
[10:04] <clever> nevcairiel: ah, i see the 4 byte code now, *looks more*
[10:05] <clever> so the 4 byte 00 00 00 01 gets replaced by a 2 byte size?
[10:05] <JEEB> uhh
[10:05] <JEEB> no
[10:05] <JEEB> it gets replaced by a length field of the size that's set in the extradata
[10:05] <JEEB> as I said
[10:05] <nevcairiel> its usually a 4 byte size, but that information is carried in extradata, except in extradata, there its always 2
[10:05] <clever> because the header in the other hexdump starts with 01 64 00 29
[10:05] <clever> ah
[10:06] <nevcairiel> read the standard that describes mp4/mkv extradata
[10:06] <JEEB> oh right, the size is set in the extradata
[10:06] <clever> so the extradata starts with 0x01 0x64 as the length
[10:06] <nevcairiel> no
[10:06] <JEEB> clever, just read 14496-15
[10:06] <nevcairiel> read the standard that describes mp4/mkv extradata
[10:06] <nevcairiel> its not pure h264 NALs
[10:06] <JEEB> H.264 in Matroska copies the extradata format
[10:06] <nevcairiel> it contains extra info
[10:06] <JEEB> basically stop right here and now, and grab a copy of 14496-15 :P
[10:07] <clever> i punched that into google, it gave me 14481
[10:07] <clever> silly built in calculator, lol
[10:07] <nevcairiel> put iso in front
[10:08] <clever> and is mkvextract doing anything special to convert that back?, why am i getting the 0x00 00 00 01 when i extract the video track?
[10:08] <nevcairiel> raw video tracks are usually always annexb, so yes, it converts this back
[10:08] <clever> ah
[10:08] <clever> so its not that ffmpeg is stripping it out, but mkvextract converted it on me
[10:09] <clever> and i'm a bit confused as to how omxplayer even works, because ive read its code, and its working perfectly fine with extradata
[10:10] <clever> but if i use the extradata in ffmpeg, it doesnt
[10:11] <clever> JEEB: any section i should read first in this doc?
[10:11] <clever> hmmm odd, this one is only 29 pages long
[10:11] <nevcairiel> look for avcC
[10:11] <nevcairiel> avc configuration record
[10:12] <clever> found it on page 20, *reads*
[10:16] <clever> JEEB: the omx docs make more sense then 14496-15, lol
[10:16] <ubitux> don't we have helpers already do deal with thos NALs ?
[10:16] <clever> ubitux: my decode_slice function is being ran by h264_decode_nal_units, which strips the 0x00 0x00 0x01 start code off every slice
[10:17] <clever> and i'm having to re-insert those as i pass the stream to the gpu
[10:17] <clever> vdpau does the exact same thing for those start codes
[10:17] <clever> hmmm, how does vdpau handle this header?, *looks*
[10:19] <nevcairiel> vdpau is a slice-level decoder, it only gets slice data, not the raw header
[10:19] <clever> ah
[10:19] <nevcairiel> the information in these headers is put into different data structures and submitted that way
[10:19] <clever> omx seems to work best if i give it the raw stream, the same way mkvextract gives it
[10:20] <ubitux> did you try to feed it a raw stream from ffmpeg?
[10:20] <ubitux> like, ffmpeg -i in.mkv out.h264
[10:21] <clever> *looks*
[10:21] <clever> i think thats re-encoding everything as it goes, not just extracting it
[10:21] <JEEB> clever, well the stuff that is done in Matroska is exactly the same as the avc configuration record
[10:21] <clever> its only working at 3 fps
[10:21] <ubitux> clever: -c copy
[10:21] <JEEB> so you should be able to parse its info
[10:22] <JEEB> and decode the included parameter sets
[10:22] <JEEB> and then you will also get the length of the in-band length field
[10:23] <clever> JEEB: the pdf starts with class AVCConfigurationBox extends Box(`avcC`) { AVCDecoderConfigurationRecord() AVCConfig; }
[10:23] <clever> but that doesnt really say what the avcC its extending is, or what AVCDecoderConfigurationRecord is
[10:24] <clever> ah AVCDecoderConfigurationRecord is up 2 pages, *reads*
[10:25] <clever> yeah, that one seems to match up with the extradata fields
[10:26] <clever> ubitux: let me try the output of ffmpeg on the gpu...
[10:28] <clever> ubitux: yep, ffmpeg -i h264_1080p_hp_4.1_40mbps_birds.mkv out.h264 -c copy plays perfectly when fed into the gpu
[10:28] <ubitux> well then look how the raw is generated
[10:29] <ubitux> :)
[10:29] <clever> and the header in that is different as well
[10:29] <clever> 00000010  00 00 09 1c 00 01 b4 d0  3c 60 c6 58 00 00 00 01  |........<`.X....|
[10:29] <clever> nothing like the other 2 headers, it doesnt have the gd.).4 pattern in it
[10:29] <ubitux> no header at all maybe
[10:30] <clever> it still has the ascii in it later on
[10:30] <clever> 00000080  74 70 3a 2f 2f 77 77 77  2e 76 69 64 65 6f 6c 61  |tp://www.videola|
[10:30] <clever> at a different offset then the mkvextract output
[10:31] <clever> ubitux: any clue where i should look for that code?
[10:31] <ubitux> the raw muxer is libavformat/rawenc.c
[10:32] <ubitux> and basically, it's just calling a write(pkt->data, pkt->size)
[10:32] <clever> avio_write(s->pb, pkt->data, pkt->size);
[10:32] <clever> yeah, thats it, lol
[10:32] Action: clever scratches head
[10:33] <clever> so why is it coming out in a 3rd completely different header
[10:33] <ubitux> try to hex dump the data this raw muxer is writing
[10:33] <ubitux> and look if the x264 string header is one of these packet
[10:34] <ubitux> otherwise, it's written from somewhere else
[10:34] <ubitux> (which would look strange to me and i'm curious where that would happen)
[10:34] <clever> let me compile a 4th ffmpeg then
[10:35] <clever> ive got one for the vdpau disection, one inside mplayer, one in omxplayer, and now another for the rawenc debug!
[10:35] <clever> isnt that the entire point of dynamic libraries? lol
[10:37] <ubitux> :)
[10:52] <cone-332> ffmpeg.git 03Anton Khirnov 07master:074c769de93b: h264_cavlc: check the size of the intra PCM data.
[10:52] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:ededb5ffed79: Merge commit '074c769de93bf12e9f44d77e58a8c7167f9dfb13'
[10:57] <clever> ubitux: Encoder (codec none) not found for output stream #0:0
[10:57] <clever> it wont copy now that ive compiled it from source
[11:05] <cone-332> ffmpeg.git 03Anton Khirnov 07master:c453723ad7d1: gifdec: check that the image dimensions are non-zero
[11:05] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:8b2578ab452f: Merge commit 'c453723ad7d14abc5e82677eebaa6025fa598f08'
[11:05] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:564ae836fb7b: avcodec/gifdec: print error if image is not within dimensions
[11:27] <ubitux> should we drop all the *.d files at configure time so we don't need to make distclean after some files are moved, but just re-run the configure?
[11:28] <wm4> ubitux: that sounds like a good idea
[11:28] <wm4> but remove them only if configure didn't detect any changes, I guess?
[11:28] <wm4> s/didn't/did
[11:29] <ubitux> the changes are currently detected by Makefile iirc
[11:29] <ubitux> (we could make the Makefile call make config btw when that happens)
[11:29] <ubitux> (but i'm assuming this will annoy ppl)
[11:30] <ubitux> wm4: what would be the benefit?
[11:30] <wm4> or just switch to autoconf
[11:30] <ubitux> lol plz
[11:30] <wm4> rerunning configure if nothing changes (i.e. same config.h) should not force recompilation of everything
[11:30] <wm4> or use waf or other hipster shit if you hate autoconf too much
[11:31] <ubitux> recompilation?
[11:31] <ubitux> i'm just talking about the deps
[11:31] <wm4> well, if you remove the deps, you should remove the .o files too
[11:31] <ubitux> this should not cause any recompilation where not expected
[11:31] <ubitux> wm4: why?
[11:31] <wm4> I'm not sure how ffmpeg's build system works, but normally dep files are generated as part of compilation
[11:31] <ubitux> mmh
[11:32] <wm4> and if the dep files are just deleted, the dependencies won't taken into account at all
[11:32] <ubitux> they will be re-generated
[11:32] <ubitux> the .o won't have any ref
[11:32] <ubitux> unless i'm missing something
[11:32] <ubitux> the idea is drop all the .d at configure since it will re-gen them
[11:33] <ubitux> if there are remaining .o it doesn't matter, they won't be referenced anywhere
[11:34] <wm4> configure generates .d? interesting...
[11:34] <ubitux> maybe i missed something
[11:34] <ubitux> you shouldn't listen too much to me
[11:34] <clever> ubitux: cant debug ffmpeg to see how it dumps the h264 stream, it just cant when compiled from source
[11:34] <wm4> or you to me
[11:35] <clever> Encoder (codec none) not found for output stream #0:0
[11:35] <ubitux> what cmd line?
[11:35] <clever> clever at c2d ~/builds/ffmpeg $ ./ffmpeg -i /media/videos/4tb/rpi/h264_1080p_hp_4.1_40mbps_birds.mkv out.h264 -c copy
[11:35] <clever> identical to last time
[11:35] <ubitux> move -c copy before out.h264
[11:35] <ubitux> it's an output option
[11:35] <ubitux> (how old was your ffmpeg? o_o)
[11:35] <clever> clever at c2d /media/videos/4tb/rpi $ ffmpeg -i h264_1080p_hp_4.1_40mbps_birds.mkv out.h264 -c copy
[11:35] <clever> the old one worked fine that way, let me check
[11:36] <clever> ffmpeg version 1.0.7 Copyright (c) 2000-2013 the FFmpeg developers
[11:36] <ubitux> yeah right, welcome to prehistory
[11:36] <clever> yet the copyright includes the current year? lol
[11:36] <wm4> 2013... not that old
[11:36] <ubitux> it's the rev
[11:37] <nevcairiel> still 1.0
[11:37] <ubitux> unless i'm missing something
[11:37] <clever> ok, now its a spam-fest
[11:37] <ubitux> 1.0 was released in 2012
[11:37] <clever> its hexdumping all 200mb
[11:37] <ubitux> ofc
[11:37] <ubitux> use |less and check the first packets
[11:37] <clever> yep
[11:38] <clever> 00000000  00 00 02 53 06 05 ff ff 4f dc 45 e9 bd e6 d9 48 ...S....O.E....H
[11:38] <clever> 00000010  b7 96 2c d8 20 d9 23 ee ef 78 32 36 34 20 2d 20 ..,. .#..x264 - 
[11:38] <clever> thats not what 1.0.7 put into the file
[11:39] <clever> let me do another dump and compare...
[11:39] <ubitux> :D
[11:39] <ubitux> check if the raw still works :p
[11:40] <clever> yeah
[11:40] <clever> -rw-r--r--  1 pi   pi    76M Nov 22 05:26 out.h264
[11:40] <clever> -rw-r--r--  1 pi   pi   110M Nov 22 06:39 latest.h264
[11:40] <clever> size differs massively
[11:41] <clever> ubitux: and output is completely blank
[11:41] <clever> so updating to the latest git has broken it
[11:42] <clever> OMXPlayerSubtitles.cpp:172:22: error: steady_clock is not a member of std::chrono
[11:42] <clever> ubitux: maybe you can figure this one out?
[11:42] <wm4> hm what do subtitles have to do with this?
[11:43] <clever> wm4: omxplayer uses the extradata from its checkout of ffmpeg, and it works perfectly fine
[11:43] <clever> so i'm trying to av_hex_dump that
[11:43] <clever> but i cant even get omxplayer to compile
[11:43] <clever> due to the above error
[11:43] <wm4> apparently std::chrono is C++11 crap
[11:43] <wm4> so you need to update your C++ compiler?
[11:44] <clever> the prepare script installed gcc 4.7
[11:44] <clever> so i should be running the right compiler
[11:49] <ubitux> that error doesn't look related to ffmpeg :p
[11:50] <clever> yeah, i'm trying to figure out how omxplayer even works in the first place
[11:50] <clever> because its using the same extradata stuff, and it having totaly different results
[11:53] <clever> only other thing i can think of, is that the omx code sends extradata by itself, *tries*
[11:53] <cone-332> ffmpeg.git 03Anton Khirnov 07master:1f3e56b6dcc1: gifdec: convert to bytestream2
[11:53] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:7a88b7a9ad7a: Merge commit '1f3e56b6dcc163a705704e98569d4850a31d651c'
[11:59] <clever> nope, nothing
[12:00] <clever> ubitux: correction, i get a few lines that almost look like noise on the 10 foot composite cable, but it only happens when i run the program
[12:01] <cone-332> ffmpeg.git 03Anton Khirnov 07master:f0259a587ee3: h264: check buffer size before accessing it
[12:01] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:fe540ae6b72a: Merge commit 'f0259a587ee3419dd894873ea617b4c98eeaca1c'
[12:05] <Skannan> Hello I receiving the below error while installing ffmpeg during the script installation 
[12:06] <Skannan> cd /usr/local/cpffmpeg/share/man/man1 && ln -sf mplayer.1 mencoder.1
[12:06] <Skannan> install -m 755 -s mplayer /usr/local/cpffmpeg/bin
[12:06] <Skannan> Installation of mplayer.tar.gz ....... Completed
[12:06] <Skannan> Installation of FFMPEG ....... started
[12:06] <Skannan> Removing old source
[12:06] <Skannan> Cloning into ffmpeg...
[12:06] <Skannan> remote: Counting objects: 336283, done.
[12:06] <Skannan> remote: Compressing objects: 100% (76395/76395), done.
[12:06] <Skannan> remote: Total 336283 (delta 267069), reused 327256 (delta 259365)
[12:06] <Skannan> Receiving objects: 100% (336283/336283), 81.47 MiB | 3.86 MiB/s, done.
[12:06] <Skannan> Resolving deltas: 100% (267069/267069), done.
[12:06] <Skannan> ERROR: libx264 not found
[12:06] <Skannan> If you think configure made a mistake, make sure you are using the latest
[12:06] <Skannan> version from Git.  If the latest version fails, report the problem to the
[12:06] <Skannan> help plz
[12:08] <ubitux> ask #ffmpeg
[12:08] <ubitux> and stop spamming
[12:09] <cone-332> ffmpeg.git 03Anton Khirnov 07master:30be1ea33e55: matroskadec: pad EBML_BIN data.
[12:09] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:1ddc849bde0d: Merge commit '30be1ea33e5525266ad871bed60b1893a53caeaf'
[12:11] <cone-332> ffmpeg.git 03Aurelien Jacobs 07master:8b516f154a0a: matroskadec: use correct compression parameters for current track CodecPrivate
[12:11] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:d86e27758f4d: Merge commit '8b516f154a0a08655cec2d13d12aadc58cae0b1c'
[12:27] <cone-332> ffmpeg.git 03Anton Khirnov 07master:ca41c72c6d95: motionpixels: clip VLC codes.
[12:27] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:8c63ee4296a8: Merge commit 'ca41c72c6d9515d9045bd3b68104525dee81b8d0'
[12:34] <cone-332> ffmpeg.git 03Anton Khirnov 07master:de4ec972c06d: vc1: fix a memleak.
[12:35] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:d7fbb63122b8: Merge commit 'de4ec972c06d9047bc1b73bb13f858a5d77d8df0'
[12:40] <cone-332> ffmpeg.git 03Anton Khirnov 07master:ce9bba5340a5: avidec: fix a memleak in the dv init code.
[12:40] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:4b3b702f9256: Merge commit 'ce9bba5340a5fb6f38974a19af019dd6aa2da035'
[12:49] <cone-332> ffmpeg.git 03Anton Khirnov 07master:c918e08b9cc9: truemotion1: make sure index does not go out of bounds
[12:49] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:bdf831859f0d: Merge commit 'c918e08b9cc9ce8d06159c51da55ec5ab018039a'
[12:53] <cone-332> ffmpeg.git 03Anton Khirnov 07master:430d12196432: pcx: round up in bits->bytes conversion in a buffer size check
[12:53] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:8617be28d074: Merge commit '430d12196432ded13f011a3bf7690f03c9b2e5d6'
[13:02] <cone-332> ffmpeg.git 03Diego Biurrun 07master:0ba8ba165b84: aacps: Adjust some const qualifiers to suppress warnings
[13:02] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:9e22b8aca0fd: Merge remote-tracking branch 'qatar/master'
[13:04] <ubitux> any idea why most (all?) the arm assembly has numbered labels instead of named one?
[13:06] <ubitux> i see some named labels in jrevdct_arm.S but that's really one of the few ones
[13:06] <ubitux> i'm assuming it's exporting syms while numbering doesn't?
[13:06] <ubitux> (the '.' thing in x86 doesn't work for the arm assembler?)
[13:10] <wm4> isn't it a gas thing?
[13:22] <ubitux> dunno
[13:22] <ubitux> probably :p
[13:48] <saste> wbs: can you explain this?: https://trac.ffmpeg.org/ticket/3158
[13:49] <wbs> saste: yes, VBR is a "if it works for you, good for you, if it doesn't, don't complain" thing
[13:50] <wbs> VBR is not supported at all in the library as it comes from upstream, I just removed some lines of code that made it impossible to enable the code that actually is there
[13:50] <wbs> so for some bitrate/samplerate/vbr mode combinations it works, for some it doesn't
[13:51] <wbs> and there should have been a warning when you try to use VBR mode that says "if this doesn't work, then don't use VBR mode", why not read that and follow what it says?
[13:52] <saste> wbs, yes, i'll close the ticket and stress that in the docs
[13:55] <clever> ubitux: ah, i found the std::chrono problem
[13:55] <clever> ubitux: the script to prepare everything including gcc 4.7, tried to use bash features in sh
[13:55] <clever> so it failed to setup 4.7 properly
[13:59] <ubitux> wtf audacity still requires a 2yrs old ffmpeg
[14:09] <wm4> lol audacity
[14:10] <JEEB> I think that was one of the apps that the debian maintainer had to kick in the arse as well
[14:19] <ubitux> JEEB: and what happened?
[14:28] <db0__> hi guys
[14:28] <db0__> ubitux asked me to re-design the website
[14:28] <JEEB> ubitux, I would guess either upstream got a patch that used newer APIs, they fixed it themselves or debian now patches audacity to work with newer APIs
[14:28] <ubitux> JEEB: 'k, thx
[14:29] <db0__> I just wanted your opinion on the global color: white on black or black on white?
[14:29] <ubitux> saste: you were curious about the progress, ^
[14:29] <JEEB> or...
[14:29] Action: JEEB checks a few things
[14:31] <JEEB> http://packages.debian.org/jessie/audacity
[14:31] <JEEB> seems like debian doesn't have avcodec as a dependency for audacity any more
[14:31] <ubitux> yeah ok i see
[14:32] <JEEB> and then the version from unstable has it re-enabled agian
[14:32] <JEEB> *again
[14:32] <JEEB> with an ass-old avcodec :|
[14:33] <JEEB> seems like they couldn't get them to update the API usage
[14:33] <JEEB> excuse me while I herp a derp
[14:33] <wm4> to be fair, the API changes are always horrible
[14:33] <wm4> I don't understand why ffmpeg doesn't just emulate old APIs
[14:42] <nevcairiel> I hate endless emulation layers
[14:43] <nevcairiel> once you start they just bloat up and you can never clean up
[14:43] <av500> allways put an emulation layer into a wrapper
[14:56] <saste> ubitux, db0__: ideally it would be nice to support multiple CSS layouts
[14:58] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:80c85460fd1b: doc/encoders/libfdk_aac: use @ref to reference libfaac
[14:58] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:9459569897a2: doc/encoders/libfdk_aac: fix a few typos
[14:58] <ubitux> saste: you can harass db0__ only i'm not responsible anymore ;)
[14:58] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:e2ad4e65a1d3: doc/encoders/libfdk_aac: state that VBR support is experimental
[14:58] <saste> db0__, can you already show something?
[14:58] <saste> a link to an experimental website, a png?
[15:04] <db0__> saste: it looks terrible
[15:04] <db0__> http://db0.galo.pe/ffmpeg-web/htdocs/
[15:05] <Romain___> it's very nice, sober
[15:09] <saste> db0__, project colors have been white, green, and grey, but this can be changed
[15:10] <saste> about the embedded logo in the menu bar
[15:10] <ubitux> db0__: if you can make the <table> readable, that would be nice
[15:10] <ubitux> (different colors for odd & even lines)
[15:10] <saste> this may be a good idea, on the other hand we couldn't show custom logos no more
[15:10] <db0__> saste: I planned to use those colors
[15:10] <saste> what i mostly dislike about the current ffmpeg design:
[15:11] <saste> the box around headers, which are a bit ugly and look old style
[15:11] <saste> sick green color used for h3 headers
[15:11] <db0__> ubitux told me the logo is now owned by libav so I have to design a new one
[15:11] <ubitux> the small one you used, yes
[15:12] <ubitux> we have a favicon you can use though
[15:12] <Compn> dropdown menus ?
[15:12] <db0__> isn't it the same...?
[15:12] <ubitux> db0__: no
[15:12] <db0__> ok
[15:13] <Compn> db0__ : i dont like dropdown menus much
[15:13] <ubitux> http://ffmpeg.org/favicon.png ` http://libav.org/favicon.png
[15:13] <ubitux> it represents the same thing ofc :p
[15:13] <saste> ubitux, "is now owned by libav"
[15:13] Action: ubitux doesn't like much dropdown menus either
[15:13] <JEEB> reminds me that stunt by mru was one of the dumbest things in 2011
[15:13] <ubitux> saste: i didn't word it like this ;)
[15:13] <saste> that was never properly demonstrated
[15:14] <JEEB> not to mention that mru finally left libav a few months ago, which I kind of like in a way :P
[15:14] <saste> indeed the whole thing is much controverted
[15:14] <db0__> that's what most flat websites use today, but i can change it
[15:14] <ubitux> saste: yeah but let's put aside the flaming :)
[15:14] <saste> ubitux, yes, but don't assume wrong things
[15:15] <ubitux> db0__, Compn; the thing i don't like with drop down menu is that we generally have to look for things in those menus
[15:15] <ubitux> if they are always expanded, we locate them much faster
[15:16] <ubitux> JEEB: if we get the logo back, do you think it will bring back mru to libav?
[15:17] <ubitux> let's try, they might thank us ;)
[15:17] <JEEB> haha
[15:17] <nevcairiel> doubtful, he  left for reasons
[15:17] <JEEB> yeah
[15:17] <JEEB> "everyone else is dumb", which seemed to be his motto in surprisingly many things
[15:18] <nevcairiel> its called arrogance
[15:18] <JEEB> yup
[15:18] <ubitux> let's not bitch about dead ppl, they can't defend themselves
[15:18] <JEEB> ( Ÿ
[15:19] <ubitux> ok, with the exception of steve jobs, we can bitch on this one i guess
[15:19] <Compn> yea, get on with it guys
[15:19] <Compn> forget the logo
[15:19] <Compn> whats next :)
[15:19] <Compn> someone porting spp filter and finally rm -rf libmpcodecs ?
[15:19] <ubitux> spp is ported
[15:47] <ubitux> btw, any feedback on cross compiling ffmpeg with clang vs with a random gcc toolchain?
[15:49] <Mavrik> huh... ffmpeg compile breaks very nicely with LTO
[15:50] <ubitux> (s/clang/llvm)
[15:50] <ubitux> Mavrik: you need to disable inline asm
[15:51] <Mavrik> mhm
[15:51] <Mavrik> figured that's not supported properly yet :)
[15:51] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:320389f88b42: lavu/dict.h: apply various fixes/extensions to doxy
[15:51] <JEEB> ubitux, the last I tried clang 3.3 it was all fine'ish?
[15:51] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:e782eea183ba: lavu/dict.h: extend/clarify docs for av_dict_parse_string()
[15:52] <JEEB> had to build my own clang and use it because the gcc and clang that came with os x 10.6 and some early xcode 4 were too old :)
[15:52] <ubitux> JEEB: i've heard "it's slower and creates bigger binaries"
[15:52] <ubitux> so i was wondering if i should mess with a toolchain or no
[15:52] <JEEB> yes, the optimization isn't as good
[15:52] <JEEB> at least with x86_64
[15:52] <JEEB> or IA32
[15:53] <JEEB> also clang-built binaries might not always be liked by gdb
[15:53] <ubitux> ah sorry, i'm talking about cross compiling for arm
[15:53] <Mavrik> depends on which ARM
[15:53] <Mavrik> I've found clang to be horribly broken for some platforms... would probably work for Apple devices which compile their apps with clang now
[15:53] <ubitux> arm7, cortex a8
[16:02] <sspiff> ubitux: that's ARMv7, not ARM7
[16:02] <ubitux> yeah sorry
[16:02] <ubitux> not familiar with all those naming :)
[16:03] <ubitux> btw, anyone heard about http://en.wikipedia.org/wiki/MMX_%28instruction_set%29#MMX_in_embedded_applications ?
[16:03] <ubitux> should/could we support such thing? (port mmx code to arm?)
[16:05] <wm4> "Intel Wireless MMX Technology"
[16:05] <wm4> wow
[16:05] <wm4> did the marketing team have their hands in that again
[16:05] <av500> thats so old
[16:05] <wm4> reminds me of the "internet" shit in pentium 3
[16:05] <ubitux> simd over wifi
[16:05] <sspiff> av500: I think marvell still sells PXA things
[16:06] <av500> yes
[16:06] <av500> hotrodded ARM9s with wMMX
[16:07] <sspiff> av500: also in-house designs
[16:07] <sspiff> they have  them on application processors, it seems
[16:08] <ubitux> the point is, most hw decoder are still shitty, so if they have wmmx/wmmx2, maybe we could use our current x86 mmx optims somehow
[16:08] <ubitux> typically this thing: http://www.solid-run.com/mw/index.php?title=CuBox_hardware_specification
[16:09] <sspiff> their sheeva plugs and P4J has it, so that's quite a few devices
[16:09] <sspiff> ubitux: I know that thing, not sure if many people have one/run ffmpeg on it though
[16:09] <av500> that thing will note decode HD even with wmmx
[16:09] <av500> it does not with neon on other SoCs
[16:10] <ubitux> even with threading?
[16:10] <ubitux> it's a dual core
[16:10] <av500> no
[16:10] <av500> or well, maybe taking like 100% cpu
[16:11] <av500> then why not use the HW decoder?
[16:12] <ubitux> because it sucks i guess
[16:12] <av500> dunno why it should
[16:12] <ubitux> what about 10-bits?
[16:13] <av500> nope
[16:13] <av500> good luck with 10bit HD in SW though :)
[16:13] <ubitux> well then&
[16:13] <ubitux> yeah sure
[16:16] <saste> who knows why we kept git-howto.txt?
[16:16] <saste> michaelni, ?
[16:17] <michaelni> saste, dunno, i took a quick look at the texi when the question was posted ...
[16:19] <ubitux> av500: do you know hw decoder supporting 10bit? vmeta maybe?
[16:19] <av500> vmwhat?
[16:20] <ubitux> vMeta
[16:20] <ubitux> marvell again
[16:29] <ubitux> well i guess nothing supports 10-bit
[16:32] <av500> no demand for it :)
[16:34] <ubitux> i demand!
[16:35] <av500> :)
[16:35] <av500> now become CEO at marvell
[16:35] <ubitux> sadness :(
[16:55] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:68590650f05f: lavu/avstring: add av_utf8_decode() function
[16:55] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:e87190f5d20d: ffprobe: check for errors, and abort immediately
[16:55] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:11cba3ba9df1: ffprobe: add support for nested options in writer contexts
[16:55] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:cbba331aa02f: ffprobe: implement string validation setting
[16:56] Action: ubitux reviewing saste commits post push
[16:56] <ubitux> saste: you don't need to add a comma after the last "NB" entry in enums
[16:57] <ubitux> same for { NULL } trailing entry in stables
[17:02] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:d20241c9b1f3: ffprobe: remove various useless ","
[17:02] <ubitux> :)
[17:06] <saste> http://ffmpeg.org/trac/ffmpeg/query?status=!closed&component=FFprobe
[17:06] <saste> ubitux, i leave that to you :)
[17:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:7865759409b2: avformat/avidec: Dont assert the existence of an index for video streams.
[17:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:ba992711f79c: avcodec/hnm4video: check that packetsize is at least 8
[17:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:6060234d43dc: avcodec/mjpegdec: check len in mjpeg_decode_app() more completely
[17:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:0398b7cbd39a: avcodec/hnm4video: check intraframe size
[17:11] <ubitux> saste: -f lavfi ftw
[17:11] <ubitux> saste: i might do it if you simplify the api ;)
[17:13] <saste> michaelni, ok to remove git-howto.texi
[17:13] <saste> ?
[17:47] <cone-332> ffmpeg.git 03Zhang Rui 07master:393d80cc278e: http: Support relative URL redirection
[17:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:1d19f1b196c7: Merge commit '393d80cc278e2b2f5c9e7805db176e6f28335a33'
[18:07] <cone-332> ffmpeg.git 03Martin Storsjö 07master:be4edda6731a: http: Expose the content location via an AVOption
[18:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:15b2ec57ccae: Merge commit 'be4edda6731a341d3fdeaa0e57753dc396790362'
[18:15] <cone-332> ffmpeg.git 03Martin Storsjö 07master:8c929098141e: hls: Check whether the AVIOContext contains a new redirected URL
[18:16] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:9440e4706793: Merge commit '8c929098141ebc94ad3f303521c520bb3dc6d8f6'
[18:28] <cone-332> ffmpeg.git 03Martin Storsjö 07master:56c2337004d5: hls: Avoid reading outside of the allocated array
[18:28] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:9c00f9ada690: Merge remote-tracking branch 'qatar/master'
[18:32] <db0__> do you mind if I rewrite some pages?
[18:33] <db0__> I want to make it much simpler, add big buttons that are easy to find and replace long sentences by important keywords
[19:02] <ubitux> db0__: yes, but track each change so we can review them
[19:58] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:e4eb2c957b68: avcodec/rv10: revert hunk from ce9f5b13ed1eb1882479574c12af24cf0e2b8aaf
[19:58] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:2e97e244097c: avformat/ipmovie: check OPCODE_INIT_VIDEO_BUFFERS size more completely
[20:17] <ubitux> BBB: ping
[20:17] <ubitux> BBB: opinion on http://b.pkh.me/0001-avcodec-vp9dsp-add-DC-only-versions-for-idct-idct.patch ?
[20:23] <BBB> that's a pretty good gain actually
[20:23] <BBB> sure why not
[20:24] <ubitux> i might get even more easily
[20:27] <BBB> how so?
[20:28] <ubitux> moving out the t rounding
[20:28] <BBB> hm yes
[20:28] <BBB> I wonder if the compiler would know that
[20:28] <BBB> compilers always have surprisingly obnoxious behaviour
[20:32] <ubitux> mmh strangely it looks a little slower
[20:32] <ubitux> i guess i'll keep that version
[20:37] <cone-332> ffmpeg.git 03Clément BSsch 07master:64821f5a7cc8: avcodec/vp9dsp: add DC only versions for idct/idct.
[20:51] <siriussirius> hi
[20:52] <siriussirius> are there any news about MVC support on ffmpeg?
[20:56] <Compn> siriussirius : h264 3d you mean ?
[20:56] <Compn> er 3d bluray
[20:56] <Compn>  i mean
[20:56] <siriussirius> yep
[20:56] <Compn> i dont think anyones working on it , no
[20:56] <Compn> not many h264 people , not many 3d blurays, i wonder if we even have many samples
[20:56] <Compn> should ask vlc ...
[20:57] <Compn> i bet hes got 3d bluray porn
[20:57] <Daemon404> nobody anywhere gives any crap about 3d bluray afaik
[20:57] <Daemon404> ... maybe j-b
[20:57] <Daemon404> but iirc he doesnt.
[20:57] <Compn> he asked about it at vdd
[20:57] <Compn> because 3d hardware should be getting real cheap now
[20:57] <Daemon404> he calle it a fad, and low priority
[20:57] <Daemon404> didnt he?
[20:57] <siriussirius> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013#H.264_Multiview_Video_Coding_.28MVC.29
[20:57] <Daemon404> anyway i definitely dont care
[20:57] <Compn> of course its a fad, but theres no open source for that market
[20:58] <Daemon404> i think it looks like crap
[20:58] <Daemon404> and it makes my head hurt
[20:58] <Daemon404> literally.
[20:58] <Compn> many people get headaches with 3d tech 
[20:58] <siriussirius> thats true, specially with active glasses
[20:58] <Compn> siriussirius : do you have 3d discs ?
[20:58] <siriussirius> but passive ones are fine
[20:59] <siriussirius> yep
[20:59] <Compn> which ones ?
[20:59] <Compn> avatar ?
[21:00] <siriussirius> yep, Despicable Me 2
[21:01] <siriussirius> Gravity in the near future
[21:01] <Daemon404> they all have a blurry look to me
[21:01] <siriussirius> that deserves to be watched in 3D
[21:02] <siriussirius> ok
[21:02] <siriussirius> that's all, I just wonder if someone starts to work on it
[21:02] <siriussirius> thank you guys
[21:02] <siriussirius> ;)
[21:03] <Compn> no problem
[21:03] <Compn> just curious what people are watching :)
[21:04] <siriussirius> nye!
[21:04] <siriussirius> bye!
[21:09] <llogan> michaelni: I still have the message delete button on trac
[21:09] <llogan> s/message/ticket
[21:09] <michaelni> ?
[21:10] <llogan> you mentioned that you did not want that functionality via the web interface
[21:11] <michaelni> llogan, true but theres too much spam
[21:12] <llogan> ok
[22:27] <BBB> ubitux: I'd be surprised if it was slower, would expect it more or less to have no effect if the compiler was clever, but what do I know
[22:28] <ubitux> yeah i was surprised as well, but didn't investigate much
[22:28] <BBB> fair enough, not crazy important I suppose
[22:28] <BBB> good speed gain though
[22:28] <BBB> I'm 3/4 done with frame-mt I think
[22:28] <ubitux> awesome :)
[22:28] <BBB> have two pieces that need some refactoring
[22:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:a7f27453f64d: avformat/mov: Check that we have a stream before accessing it in mov_read_ares()
[22:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:5a08ba5381cf: avcodec/hnm4video: check offset in decode_interframe_v4() more completely
[22:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:78446f0d9d6a: avcodec/hnm4video: fix write offset checks in decode_interframe_v4()
[22:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:b33f3246e2ec: avcodec/hnm4video: fix missing newlines in error messages
[23:27] <cone-332> ffmpeg.git 03Clément BSsch 07master:004f3b154b7c: avcodec/vp9dsp: pass dconly bit as macro argument.
[23:28] <ubitux> BBB: and so you kept the fb[]?
[23:29] <BBB> no
[23:29] <BBB> but I'm not sure it's optimal
[23:29] <BBB> let me finish mt so I can figure it out and then I'll know what to do with that patch
[23:29] <BBB> I finished one of the refactorings and am now doing the second, then I'll probably need to debug for a few days, and then it should work
[00:00] --- Sat Nov 23 2013