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

[burek]

[01:23] <burek> lake, which machine are you using this example on?
[01:24] <burek> is it an x86-like stuff or an embedded-like type of device
[01:31] <llogan> burek: what plans do you have for your pi?
[01:32] <burek> its hardware (ram or buses or something) is really slow
[01:32] <burek> so, I'm moving away from it
[01:32] <llogan> to something new?
[01:32] <burek> it can't even just simply remux full hd video from the webcam
[01:32] <burek> (without re-encoding)
[01:32] <llogan> damn
[01:32] <burek> cpu stays at 15% but the video is awfully choppy
[01:33] <burek> which seems like it has got something to do with bus speed or eth or something
[01:33] <burek> I'm looking into some android tablets and stuff
[01:33] <burek> hope that'll work better
[01:34] <drv> the rpi ethernet is connected via usb or something silly like that
[01:34] <llogan> i'd like to make a rail system for timelapse, but i doubt i'll get off of my ass and do it
[01:34] <burek> no way..?
[01:34] <drv> http://hardware.slashdot.org/story/12/08/24/2228251/serious-problems-with-usb-and-ethernet-on-the-raspberry-pi
[01:38] <burek> maybe things will get better during time.. at least i hope
[03:15] <matej_k> is there a reasonable easy way to detect the pyramid level from H264 stream?
[03:16] <matej_k> I get H264 stream from MKV, I need to remux it as TS, but I don't have DTS and there is no buffering period SEI
[04:41] <lake> burek: it's an x86 laptop
[04:44] <lake> burek: i tried to simplify the command, per llogan's suggestion. yes, that worked. which make the assumption on v4l or the codec i am trying to use i guess.
[04:44] <lake> *video codec
[04:50] <lake> what i mean is, i guess there's some crap going on w/ v4l2 becuase its when i add it that it breaks
[05:26] <lake> burek: it seems likely that it has to do with my setup. i just gave pulseaudio, on top of alsa, and the original command now works. hmmmm
[05:26] <lake> this is exciting and interesting
[13:23] <tuxx_> hey guys
[13:23] <tuxx_> there seems to be a memory leak in av_write_frame/av_interleaves_write_frame
[13:24] <tuxx_> i am encoding frames which I am receiving from a remote framebuffer (VNC) into flashsv with an avi container
[13:24] <tuxx_> and i get a gradual increase of memory usage until the process is killed by the linux kernel oom killer when encoding and using av_write_frame
[13:25] <tuxx_> if i dont comment out av_write_frame then the leak does not occur
[13:25] <tuxx_> anyone have an idea what this could be?
[13:25] <divVerent> do you have one or two streams?
[13:25] <tuxx_> http://pastebin.com/nB6hTSMn
[13:26] <divVerent> I mean, is audio involved too?
[13:26] <tuxx_> divVerent: no, no audio
[13:26] <divVerent> and does the avi file grow while writing?
[13:26] <tuxx_> divVerent: hi btw.. you helped me last time, I believe
[13:26] <tuxx_> yea it does .. i can playback as well
[13:26] <divVerent> even while it's writing?
[13:27] <tuxx_> does the file increase while its writing?
[13:27] <tuxx_> yes, it does?
[13:27] <tuxx_> i'm not sure i understand your question actually
[13:27] <divVerent> asking, as I had an issue in my own code already that had caused libavformat to buffer the whole file
[13:27] <divVerent> and only write it out on closing
[13:28] <tuxx_> divVerent: oh...
[13:28] <tuxx_> that *COULD* be the issue...
[13:28] <divVerent> too bad I don't remember how I fixed it
[13:28] <tuxx_> but its not like it doesnt write any info, because it does
[13:29] <tuxx_> the file is definately growing
[13:29] <tuxx_> however I dont know if the cache may be increasing
[13:29] <divVerent> also, in my case it happened because of bad audio pts
[13:29] <divVerent> IIRC, that is
[13:29] <tuxx_> its not a classical memory leak, since duma and valgrind are not complaining
[13:29] <tuxx_> someting IS still pointing to it
[13:30] <tuxx_> aprox 4kb every 10 seconds
[13:30] <tuxx_> is getting lost
[13:30] <divVerent> hm... damn, I wouldn't even notice that tiny amount in my code ;)
[13:30] <tuxx_> divVerent: well it runs on an embedded device
[13:30] <divVerent> how many fps do you encode on average?
[13:30] <tuxx_> divVerent: and the device fills up over night and in the morning you see the oom
[13:31] <tuxx_> divVerent: well the container is set to 16fps but i encode in a variable frame rate
[13:31] <divVerent> i mean the average
[13:31] <divVerent> so like 10fps average?
[13:31] <tuxx_> divVerent: much less... like 1 fps
[13:31] <divVerent> ok
[13:31] <tuxx_> divVerent: because all that changes is the clock
[13:31] <divVerent> so like 400 bytes wasted per frame
[13:31] <tuxx_> divVerent: yea
[13:31] <divVerent> that's an odd number, also doesn't seem to correspond to any file indexes
[13:32] <divVerent> still, avi has an index, and MAYBE ffmpeg is just inefficient at maintaining its index data
[13:32] <divVerent> did you try another container?
[13:32] <tuxx_> let me try
[13:32] <divVerent> especially as every frame is a keyframe in your codec
[13:32] <divVerent> and IIRC in avi, all keyframes get recorded into that index
[13:33] <divVerent> also, if you don't need seeking, you probably can also try writing index-less avi
[13:34] <divVerent> easiest way to force ffmpeg's avi output to write no index, is to write to stdout instead to a file
[13:34] <divVerent> ;)
[13:38] <tuxx_> divVerent: you were right.. it only happens with avi
[13:39] <tuxx_> if i use flv it doesnt occur!
[13:40] <divVerent> ok
[13:40] <divVerent> still weird
[13:40] <divVerent> because avi index structs are more like 20 bytes per frame
[13:40] <divVerent> and not 400
[13:41] <tuxx_> divVerent: well... its gone if i use flv
[13:41] <divVerent> but yes, for long time recording you really should use an index-less format
[13:41] <divVerent> like .nut, or whatever works for you :P
[13:41] <divVerent> don't know what flv is, but if it's good, it's good
[13:41] <divVerent> I mean, whether it has index or not, etc.
[13:42] <tuxx_> divVerent: its a flash container.. im using flashsv as a codec
[13:42] <divVerent> well, then you shoudl be using flv anyway, right?
[13:42] <divVerent> so you can use it directly with a flash based player
[13:43] <tuxx_> divVerent: well we dont really want it in a flash based player :)
[13:43] <JEEB> divVerent, I really wouldn't recommend using nut anywhere unless both reading and writing is done by ffmpeg
[13:43] <divVerent> OH, now I see why you got 400 bytes
[13:43] <divVerent> you used avi
[13:43] <divVerent> with VFR
[13:43] <JEEB> lol
[13:43] <divVerent> but avi has no VFR support
[13:43] <divVerent> so it put lots of empty frames in between your real frames
[13:43] <divVerent> to hit the "maximum" frame rate (your 16 fps)
[13:43] <divVerent> now 20 * 16 = 320, that fits the estimated 400 bytes from your memory growth
[13:44] <divVerent> I think we found all the leaked bytes now ;)
[13:44] <divVerent> jeeb: only mentioned nut because it's one of the few well working indexless formats...
[13:45] <divVerent> I wish there were better ones
[13:45] <JEEB> mkv? flv?
[13:45] <divVerent> i.e. more supported ones
[13:45] <divVerent> oh right, mkv :P
[13:45] <divVerent> but still is way too complex
[13:45] <divVerent> flv doesn't work with "every codec" IIRC
[13:45] <JEEB> yes
[13:45] <JEEB> mkv for that
[13:45] <Emmanuel_Chanel> Hello!
[13:45] <divVerent> mkv that binary XML shit :P
[13:45] <divVerent> although nut is not much less complex than mkv :(
[13:45] <JEEB> well better than a container that has differing implementations
[13:46] <JEEB> the last I checked the various nut implementations didn't abide to a single "spec"
[13:46] <divVerent> there is even more than one?
[13:46] <JEEB> or well, I didn't but someone brought it up
[13:46] <JEEB> yes, I think mplayer or something implemented nut as well
[13:46] <divVerent> I still want to finally find a SIMPLE container for streaming data so I can run ffmpeg in an external process
[13:46] <divVerent> and profit from a stable way to use ffmpeg without having to adjust to every single stupid API change
[13:47] <divVerent> from an external program
[13:47] <JEEB> nut is generally used for raw video with timestamps methinks, and both sides being a libavformat-based parser :D :D
[13:47] <divVerent> ideally something as trivial as <header> <type=V> <pts> <videoframe> <type=A> <pts> <audioframe> ...
[13:47] <divVerent> well, I do want timestamps in both streams
[13:47] <divVerent> but I want it to be simple :P
[13:47] <divVerent> it's enough if it only supports pcm audio and rawvideo
[13:48] <divVerent> basically, add audio and pts support to yuv4mpeg and I'm REALLY happy ;)
[13:48] <JEEB> hehe
[13:48] <Emmanuel_Chanel> I tried the update of ffmpeg on https://ffmpeg.org/trac/ffmpeg/wiki/UbuntuCompilationGuide just now.
[13:48] <JEEB> nut actually is useful for that kind of use case, but generally putting compressed video into it isn't done
[13:48] <divVerent> problem is, I basically want to feed ffmpeg audio AND video via IPC as easily as possible
[13:48] <Emmanuel_Chanel> And ffmpeg didn't work. So I reverted the nightley version that I tried the last time.
[13:48] <divVerent> there is one workaround of using two separate pipes to ffmpeg
[13:49] <divVerent> but then that often leads to deadlocks
[13:49] <divVerent> and is VERY clumsy to do on windows
[13:49] <JEEB> also you pretty much want to make sure that nut is being frozen spec-wise in that case :P If you're going to implement your own parser or whatever
[13:49] <divVerent> jeeb: have you SEEN the nut spec?
[13:49] <divVerent> it's WAY too complex for this use case
[13:49] <JEEB> the last I saw a text file like that was ages ago
[13:50] <divVerent> yes, that one
[13:50] <divVerent> it's so totally overengineered...
[13:50] <divVerent> I mean, bad enough that every frame needs a checksum
[13:50] <JEEB> but yeah, that's IIRC the only active use case for nut atm
[13:50] <JEEB> lol
[13:50] <divVerent> so every NUT writer needs some checksum code already
[13:50] <divVerent> that's already unnecessary and annoying bloat for IPC use
[13:50] <JEEB> something a la y4m for both video and audio could be useful indeed, but herp le derp
[13:51] <divVerent> it probably already exists and we just don't know it ;)
[13:51] <divVerent> or rather...
[13:51] <divVerent> I'd be pretty sure e.g. ASF is quite sane for this
[13:51] <JEEB> possibly
[13:51] <divVerent> but where is it documented? How good is the lavf demuxer of it actually?
[13:51] <divVerent> AVI is almost good for this, even
[13:51] <divVerent> too bad for my use, the RIFF chunk may exceed 4G...
[13:52] <divVerent> and then AVI gets REALLY annoying
[13:52] <divVerent> AVI with infinitely sized movi chunk would work for me ;)
[13:52] <divVerent> (and no index, of course)
[13:52] <divVerent> lack of audio pts would be annoying but toleratable
[13:52] <divVerent> lack of video pts is not existing, can use the empty frame hack ;)
[13:53] <JEEB> lol nullframes
[13:53] <divVerent> although, CURRENTLY the game engine I want this in captures video at constant frame rate anyway
[13:53] <divVerent> for realtime capture, it'd be useful to have real VFR support though
[13:53] <divVerent> I actually have existing code in a branch that worked with an old version of ffmpeg
[13:54] <divVerent> but I got annoyed with maintaining it and adjusting for every single API change
[13:54] <divVerent> AND also keeping the old way working too as our users may have older versions of the library
[13:54] <divVerent> so it never even entered master
[13:54] <divVerent> and I stopped maintaining it
[13:54] <divVerent> also, ABI change... I actually even need a stable ABI for this
[13:54] <divVerent> and the only somewhat stable ABI ffmpeg has is the command line
[13:55] <divVerent> (and when that breaks, it's easy to fix)
[13:55] <divVerent> so I may actually implement this for Linux at least using two streams, one pcm, one yuv4mpeg, and that'll work fine
[13:55] <divVerent> on two fds
[13:55] <divVerent> on Windows, however, such code tends to only make trouble
[13:55] <divVerent> like, process still hanging around when the engine dies, and being unkillable
[13:56] <divVerent> so I basically want to avoid doing my own file handle management using CreateProcess() etc.
[13:56] <divVerent> and just rely on standard libc stuff like popen(), and blame the libc if stuff breaks ;)
[13:57] <divVerent> also, that way I'd avoid having to do my own pipe buffering and nonblocking IO
[15:17] <Emmanuel_Chanel> Hello!
[15:17] <tuxx_> divVerent: still there?
[17:29] <emerica_> tests/fate/acodec.mak:26: *** No such config: CONFIG_PCM_S8_PLANAR_ENCODER.  Stop.   latest git pull?
[17:32] <ubitux> re-run configure
[17:32] <ubitux> distclean if necessary
[17:32] <ubitux> if it doesn't git clean
[17:33] <emerica_> distclean wasnt going with the same error, i'll try the others ;)
[17:33] <emerica_> through does after a configure
[17:59] <joseph> Wow, this channel exists?
[17:59] <ubitux> & ?
[18:00] <joseph> Just typed in /join #ffmpeg on a lark, and there you are. Was surprised, that's all. Guess I shouldn't, considering freenode is amazing.
[18:00] <ubitux> :)
[18:19] <tr33fall> hi all
[18:20] <tr33fall> i had time to continue my tests with ffmpeg but i continue with 3gp problem
[18:20] <tr33fall> pastebin is here: http://pastebin.com/LZ346U9e
[18:32] <tr33fall> any ideas
[18:32] <tr33fall> i even try adding -enable-muxer=3gp
[18:33] <tr33fall> but with no luck
[18:34] <JEEB> 3gp is a modification of the iso media container, which on the other hand comes from mov
[18:35] <JEEB> enable mov/mp4 muxing :P
[18:35] <JEEB> also what is it with android people and having very long configure lines?
[18:37] <tr33fall> dont understand why the "long configure lines" ? :)
[18:37] <tr33fall> i added the mp4 muxer still gives that error
[18:38] <JEEB> did you even check under which name the muxer you need is under :P
[18:39] <JEEB> also wouldn't it be ok to just set the output file name to dot-3gp and have ffmpeg decide the "format" it wants to use for it?
[18:42] <tr33fall> "did you even check under which name the muxer you need is under :P" not really
[18:42] <tr33fall> i cant find 3gp
[18:42] <tr33fall> so i asked :P
[18:42] <tr33fall> but you said also mov
[18:42] <tr33fall> ill try with "mov"
[18:47] <JEEB> mp4 and variants of it are naturally under movenc.c, but that's as far as I my "I didn't look this shit up" knowledge goes :P
[18:47] <JEEB> also as I said
[18:47] <JEEB> setting file name to something and not setting the output format generally should work, if it's command line
[18:57] <tr33fall> ok thanks JEEB
[20:23] <okhattab> Hi everyone.  I was hoping someone would be able to make some sense of this error im receiving while trying to build omxplayer. http://fpaste.org/YxUt/  thank you in advance. (Raspi Fedora Remix)
[21:31] <burek> okhattab, you probably missed the proper channel
[22:04] <samek__> Burek
[22:05] <samek__> you were right when you said couple of days ago either rtmp muxer or network connection.
[22:05] <burek> did you solve that issue?
[22:05] <samek__> It was the network connection ... well some firewall infront of the box made the ffmpeg think it has a open connection but it was closed
[22:06] <samek__> yes it works like a charm
[22:06] <burek> good :)
[22:06] <okhattab> burek: is there a channel you could suggest?
[22:06] <samek__> but i had to dig into the code to find out it should not stall at all
[22:06] <samek__> anyway thanks for your support
[22:06] <burek> samek__, you're welcome :beer: :)
[22:07] <burek> okhattab, did you try
[22:07] <samek__> btw i'm now using your static build :)
[22:07] <burek> :)
[22:07] <samek__> *even tho my compiled was fine*
[22:07] <burek> well, to be honest, it's always better to use a compiled one for your machine
[22:08] <burek> since all the acceleration will be properly enabled
[22:08] <burek> static builds tend to be as generic as possible
[22:08] <burek> in order to work everywhere
[22:10] <samek__> true but it works like a charm
[22:10] <okhattab> burek: indeed i did.  those builds are on debian.  Im tyring to build on the fedora remix (f17).  thanks though
[22:11] <burek> :beer: :)
[23:24] <bakers> I read somewhere that "-preset slower" means I don't have to to do two pass encoding. Is there any truth to that
[23:26] <JEEB> how many passes you have to do depends on what rate control algorithms you have in your encoder
[23:26] <JEEB> judging by the fact that you are using -preset , I will guess you are using libx264
[23:26] <JEEB> x264 does indeed have presets that easily let you change between settings in the line of speed vs compression
[23:26] <JEEB> but
[23:26] <JEEB> it also has a nice rate control mode called crf
[23:27] <JEEB> which is a single pass rate control mode that is as good as 2pass, and is close to "constant quality"
[23:27] <JEEB> so the preset really doesn't matter, but if you use crf and not bitrate based encoding, you only need one pass with libx264
[23:27] <JEEB> the default is crf 23
[23:28] <JEEB> you can try that, if it looks bad you change it somewhat lower and try again
[23:28] <JEEB> if it looks good, you can try higher
[23:29] <JEEB> it controls basically the general "highness" of quants used, lower quants mean more data is preserved, higher quants mean less data is preserved and more compression is pertained
[23:29] <JEEB> which is why you use the highest crf value that still looks good :)
[23:29] <JEEB> bakers, I hope this answers your question :)
[23:30] <bakers> JEEB: I can't use CRF with a target bitrate right?
[23:30] <bakers> it's just a general quality setting?
[23:31] <JEEB> well, something close to "constant quality" (closest compared to anything else available)
[23:31] <JEEB> and yes, you can't set a target bit rate, only vbv settings to keep it within some bandwidth limits
[23:31] <JEEB> because crf and bitrate based encoding are separate ways of using the same algorithm
[23:34] <JEEB> also you can do bitrate based encoding with just one pass, but you shouldn't try to set -pass 1 then, as that activates "fast first pass" defaults. And yes, slower presets are definitely useful where you have to use 1pass bitrate based encoding. But you still will not get as good compression as with crf or multipass bitrate based
[23:52] <undercash> re
[23:52] <undercash> oops sorry
[00:00] --- Sat Dec  1 2012