[FFmpeg-devel-irc] IRC log for 2011-03-04

[irc at mansr.com]

[00:00:05] <BBB> although the samples look good to me already
[00:00:06] <BBB> odd
[00:00:34] <BBB> maybe kshishkov was just too lazy to confirm binary exactness or so
[00:01:20] <Kovensky> 20:52.57 mru: aftermath is what remains after a disaster, such as a maths degree <-- lol
[00:02:56] <j45> BBB: interlace?
[00:03:12] <BBB> j45: perhaps... trying to go from small to big features
[00:03:15] <BBB> interlace is massive
[00:03:27] * j45 was afraid of that
[00:03:47] <BBB> also, the original goal was to have a set of samples for testing binary compatibility of my optimizations
[00:03:58] <BBB> not sure how I got to implementing vc1 missing features
[00:04:05] <j45> all those bbc interlace vc1 discs cause support requests for us
[00:11:34] <BBB> j45: us=?
[00:11:42] <j45> handbrake
[00:11:52] <BBB> oh I see
[00:11:56] <BBB> put a bounty on it :)
[00:12:10] <BBB> I'll see if I can look into it
[00:12:12] <j45> with who's money :p
[00:12:14] <BBB> interlace isn't easy :)
[00:12:49] * kurosu nominates xvc1-interlaced as BBB's next project
[00:12:58] <j45> hehe
[00:13:10] <BBB> kurosu: I don't think anyone would pay for that *grin*
[00:13:48] <kurosu> because people already have for xvp8 ? :p
[00:13:55] <kurosu> oh wait
[00:13:57] <kurosu> ;)
[00:16:17] <gnafu> kurosu: I just...  Wow.  xvc1?
[00:16:28] * gnafu cries inside.
[00:16:45] <j45> s/cries/dies/
[00:16:57] <mru> lies
[00:17:52] <BBB> gnafu: I thought it was rather funny :)
[00:18:15] <BBB> brb
[00:24:21] <gnafu> BBB: Didn't someone suggest xbink the other day?  I think that would be more productive than xvc1 :-P.
[00:24:43] <gnafu> Or perhaps x261.
[00:25:02] * gnafu encoded a couple movies to H.261 the other day, complete with G.711 audio.
[00:25:15] <gnafu> It's interesting to use standards that are older than yourself.
[00:26:29] <gnafu> Or at least close.  They weren't standardized until shortly after I was born, but the technologies obviously were there beforehand.
[00:29:34] <gnafu> I think I created the video and audio streams using mencoder, but only ffmpeg could manage putting them into a container (and AVI was the only thing that worked).
[00:31:51] * Sean_McG waits for his SPARC to try bootstrapping gcc again, this time with C and C++!
[00:32:21] <Sean_McG> not sure what broke, but any time I try to build with anything other than --enable-languages=c it craps out
[00:41:02] <gnafu> Do you think it's save to say I risk no patent lawsuits if I were to publish video in H.261 format with G.711 audio in an AVI container?
[00:41:05] <gnafu> *safe
[00:41:19] <gnafu> I'm guessing that's all expired.
[00:42:30] <gnafu> Perhaps a truely free baseline codec for web usage!
[00:43:16] * Sean_McG resists urge to say something
[00:43:59] <gnafu> Sean_McG: I'll stop now.
[00:44:53] <lu_zero> gnafu: use nut as container
[00:45:28] <gnafu> lu_zero: Aah, I'll have to try that ;-).
[00:48:51] * Sean_McG files another gcc bugzilla
[00:53:17] <Sean_McG> hmmm I should really convert to ZFS root.
[00:56:13] <Sean_McG> ah rats... not without another SCSI disk :(
[02:16:48] <BBB> elenril: please look at https://roundup.ffmpeg.org/issue2638
[02:51:38] <Jumpyshoes> BBB: should i comment on https://roundup.ffmpeg.org/issue421 ?
[02:54:30] <BBB> if I understand correctly, benjamin was in touch with them
[02:54:32] <BBB> wait for him
[02:54:38] <BBB> or better, ask him
[02:55:58] <Jumpyshoes> BBB: okay
[03:15:09] <Jumpyshoes> for wmaprodec.c, what is called before decode_init? i.e. what sets up the AVCodecContext before the call?
[03:41:18] <ruggles> Jumpyshoes: i think the user calls avcodec_alloc_context() then avcodec_open().
[03:46:10] <BBB> and in between, the user filsl in the AVCodecContext
[03:47:26] <Jumpyshoes> ah, okay, thanks
[04:54:52] <in3xes> Writing a video encoder from scratch in one summer is not possible??
[04:56:05] <in3xes> or decoder?
[05:01:17] * in3xes notices most of them are related to audio codecs in SoC ideas page
[05:05:06] <pengvado> quite possible, if you're good at it. the probability that a random student will do so is somewhat lower.
[05:08:02] <Dark_Shikari> I wrote a video encoder from scratch in one weekend
[05:08:07] <Dark_Shikari> and that was when I was much crappier than I am now.,
[05:08:13] <Dark_Shikari> to be fair it wasn't very good
[05:16:01] <in3xes> pengvado: Is there any open standard codec for implementation? from scratch?
[05:19:27] <kierank> in3xes: implementation of what?
[05:20:13] <in3xes> kierank: video encoder
[05:21:33] <in3xes> kierank: I would like to work on a video encoder this summer. I am looking for one.
[05:22:11] <in3xes> prefarably who's specs are open
[05:22:48] <in3xes> s/prefarably/preferably
[05:23:03] <_av500_> vp8
[05:23:07] <_av500_> cough
[05:23:09] <kierank> bear in mind video encoders are hard and iirc few (or none) have been completed at gsoc
[05:23:56] <in3xes> _av500_: Seems Dark_Shikari already completed it
[05:24:00] <in3xes> no?
[05:24:52] <kierank> no
[05:25:55] <in3xes> Oh, that was decoder :-|
[05:26:32] <_av500_> so? write a better one :)
[05:26:51] <kierank> you should try something easier in3xes
[05:27:24] <_av500_> bink
[05:27:36] <in3xes> kierank: Okay
[05:29:13] <saintdev> Dark_Shikari: moar photon!
[05:32:52] <saintdev> -ab 64k | bitrate= 70.7kbits/s with mp4 overhead
[05:33:29] <saintdev> peloverde: <saintdev> -ab 64k | bitrate= 70.7kbits/s with mp4 overhead
[05:37:39] <Dark_Shikari> god damn charliogne is such a troll
[05:38:24] <saintdev> hmm, still a ways off at high bitrates
[05:40:42] <peloverde> that's close to 10%
[05:41:19] <kierank> Dark_Shikari: i feel like trolling him back
[05:41:43] <saintdev> peloverde: well it's better than 90k when you asked for 64k
[05:41:56] <saintdev> peloverde: also muxing overhead is reported as ~5%
[05:42:17] <kierank> "So which of our sins will our children have to hide"
[05:43:39] <Dark_Shikari> kierank: talk about h.262
[05:52:59] <kierank> Dark_Shikari: you mean h.262 scalable or the crappy vlcs or what?
[05:55:01] <peloverde> if muxing overhead is 5% then the muxer is doing something wrong
[05:56:08] <saintdev> peloverde: dunno
[05:56:11] <saintdev> ./ffmpeg -y -i ~/codecs/samples/comp.wav -strict experimental -acodec aac -ab 64k ~/test.mp4
[05:56:28] <saintdev> size=     783kB time=90.82 bitrate=  70.7kbits/s
[05:56:37] <saintdev> video:0kB audio:749kB global headers:0kB muxing overhead 4.526981%
[05:57:28] <saintdev> drops considerably for higher bitrates. it's almost 10% @ 32k
[05:58:03] <saintdev> mplayer reports the same bitrate as doing the calculation
[05:58:50] <Dark_Shikari> kierank: refer to mpeg-2 has h262
[05:58:51] <Dark_Shikari> *as
[05:58:59] <kierank> oh yeah of course
[06:02:26] <Sean_McG> mru: where do I get an ebuild for gcc 4.6 SVN on ppc gentoo?
[06:04:20] <saintdev> there isn't one (probably masked) in portage?
[06:04:39] <saintdev> nope, guess not
[06:06:58] <saintdev> Sean_McG: toolchain overlay
[06:07:08] <pengvado> what, just "h262"? not "ISO/IEC 13818-2 / ITU-T H.262 / MPEG-2 Video"?
[06:08:39] <Sean_McG> lol
[06:09:11] <saintdev> Sean_McG: http://overlays.gentoo.org/proj/toolchain/browser/sys-devel/gcc/gcc-4.6.0_pre9999.ebuild
[06:09:18] <saintdev> of course that's a live svn ebuild
[06:10:02] <Sean_McG> yeah I just found that
[06:10:02] <Sean_McG> cheers
[06:17:28] <kierank> pengvado: he gets annoyed when you call standards by their H.26x name
[06:19:27] * av500 updates Asim
[06:19:27] <av500> damn, update failed
[06:19:27] * saintdev gives av500 an Asimo
[06:19:27] <av500> yes, but does it run in qemu?
[06:20:42] <saintdev> probably not, it apparently runs VxWorks
[06:28:51] <peloverde> if he doesn't like the h.names maybe he should make the mpeg versions free
[06:36:37] <av500> not his call
[06:43:34] <peloverde> why are some mpeg standards free?
[06:44:42] <peloverde> like 14496-12, -20
[06:46:50] <av500> because they are useless?
[06:47:08] <peloverde> -12 is fairly useful
[06:47:25] <superdump> non-patentable methods enclosed? (what is -12?)
[06:47:37] <peloverde> ISO Base Media File
[06:47:44] <av500> which is what?
[06:47:51] <av500> .mp4?
[06:47:51] <peloverde> .mp4
[06:47:57] <peloverde> the core parts
[06:48:03] <superdump> <@superdump> non-patentable methods enclosed?
[06:48:13] <av500> well, I can understand they do not dare to ask for money for a file format
[06:48:31] <peloverde> What does patentability have to do with it?
[06:48:45] <av500> the damage by 15 wrong RE'd version is probably higher
[06:50:19] <peloverde> everyone passes cracked specs around anyway so I doubt that is a good reason
[06:51:25] <peloverde> if they can make 14496-12 free I don't understand why they can't make 14496-10 or 13818-2 free
[06:51:53] <peloverde> except I suppose they don't need to make the latter two free because they are available elsewhere
[06:52:40] <peloverde> but when the one with your name costs money and the other guy is giving it away for free, you should expect people to call it by the other guy's name
[06:54:22] <saintdev> H.264 >> MPEG-4 AVC
[06:57:53] <thresh> morning
[06:58:34] <saintdev> what would be the correct way to do this: assert(bit_save <= 0.3f && bit_save >= -0.05000001f); ?
[06:59:06] <saintdev> -0.05000001f should be -0.05f, but the assert still triggers if bit_save == -0.05
[07:00:12] <siretart> finally, ffmpeg 0.6 got hammered into debian/wheezy. Using with a quite large hammer
[07:01:27] <elenril> nice
[07:01:33] <elenril> time for 0.7? ;)
[07:08:13] <Sean_McG> ah yes I remember Debian Eternal Beta Syndrome well
[07:36:07] <ffmpeg> i'm trying to compile my project against libavcodec, libavutil and libavformat and i'm trying to access the H264Context. Therefore, i need to include the headers libavcodec/h264.h and libavutil/internal.h. However, the compiler is complaining about av_alias16 and av_alias32 being undefined
[07:36:20] <kierank> you can't do that
[07:36:32] <kierank> H264context is not public
[07:36:40] <av500> hint: internal != external
[07:37:13] * elenril grants av500 the CaptainObvious award
[07:37:44] * av500 gladly takes it
[07:37:55] * av500 meta thanks elenril
[07:41:43] <ffmpeg> kierank: i'm not sure i understand. as far as i can tell the compiler here is complaining about av_alias16 and av_alias32 not being declared. If i look in the intreadwrite.h source file i see three av_alias union defintions. i do not understand how these three unions are all declared av_alias
[07:42:01] <kierank> you can't include h264.h in your project
[07:42:17] <av500> ffmpeg: you are compiling against non-public headers
[07:42:21] <av500> that does not work
[07:42:27] <av500> as you found out
[07:43:04] <ffmpeg> is there a convenient way to make them public?
[07:43:36] <kierank> no
[07:43:40] <kierank> what are you trying to do
[07:47:30] <ffmpeg> i m trying to access all the motion data and mode data from the H264Context
[07:47:45] <kierank> all of that is exported i think
[07:49:14] <ffmpeg> what do you mean with exported?
[07:49:39] <kierank> exported to the public api
[07:51:52] <ffmpeg> where can i find these functions?
[07:52:02] <kierank> libavcodec/avcode.h
[07:52:06] <kierank> avcodec.h*
[07:52:09] <ffmpeg> i only know of high level api (working on packets etc.)
[07:55:42] <ffmpeg> can you explain me the three av_alias definitions in libavutil/intreadwrite.h? why does this not introduce a compiler error when compiled with the makefile?
[07:56:29] <kierank> anyway this discussion for #ffmpeg
[08:10:20] <j0sh> any NEON experts still awake?
[08:11:22] <kshishkov> me knows a bit on NEON, sahib
[08:11:31] <j0sh> oh, good, you're perfect
[08:11:40] <j0sh> i'm trying my hand at NEONifying swscale
[08:11:59] <j0sh> there are a few different algos that are uses for yuv->rgb
[08:12:04] <j0sh> im not sure which is best suited
[08:12:45] <j0sh> there's a LUT approach, there's the one you used in your MMX code