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

[burek]

[00:19] <dsl420> hi
[03:53] <yep> hi, are there any known alsa recording errors? Alsa appears to work in ffplay and ffmpeg on it's own but as soon as I add x11grab after I only get about a second of audio until it cuts out. This use to work last year (back when alsa required -strict -2).
[03:55] <yep> http://pastebin.com/rijCWChK
[07:07] <mishehu> howdy folks.  having a little trouble finding with google searches how to do this...  I have mpeg2l3 files with 22050 sample rate, 64kbps cbr.  I want to convert to raw (containerless) files, and so I'm trying `ffmpeg -i input.mp3 -r 8000 -acodec pcm_mulaw -f data output.PCMU`, but I end up with "Output file #0 does not contain any stream".  (ffmpeg 2.1 I think on that machine)
[07:08] <mishehu> (doing some testing for my boss for conversions to common telephony codecs)
[07:11] <mishehu> oh curses.  nm.  looks like grep -i comes to save the day when less doesn't work as well
[07:28] <relaxed> mishehu: so you changed -f data?
[08:26] <mishehu> relaxed: yah, setting -f mulaw works to output at least.  I'll have to still test the files to see if freeswitch accepts them
[08:27] <mishehu> doesn't look like there's a raw speex output.  hope "data" works for that one
[08:31] <mishehu> or raw gsm encoding format either...  :-(
[08:36] <relaxed> wouldn't it be easier to have them in a container?
[08:42] <mishehu> not if they're expected to be raw bitstreams :-)
[08:50] <relaxed> what takes raw speex as input?
[08:51] <mishehu> freeswitch
[08:51] <mishehu> mod_native_file
[08:51] <mishehu> it takes all the native formats as raw bitstreams.
[08:52] <relaxed> mod_rtmp takes flv
[08:54] <mishehu> yes, but mod_rtmp is an endpoint module
[08:54] <mishehu> and it takes flv because that's what adobe flash uses
[08:55] <mishehu> for for audio specific injection of whatever-the-current-channel has negotiated, that's where mod_native_file handles it.
[08:55] <mishehu> I'm comparing performance differences between fs_encode and ffmpeg.
[08:56] <mishehu> since fs_encode has an approximately 4 second start-up time to it
[08:57] <mishehu> btw, Mathieu Rene had to manually add the FLV headers to the outgoing streams and strip the FLV headers on the incoming streams.  I'm fairly familiar with mod_rtmp :-)
[08:58] <mishehu> and he only ever had it use speex, none of the other flv supported codecs.
[09:00] <relaxed> you may have to pipe audio directly to speexenc
[09:00] <mishehu> yeah, I might not be able to use ffmpeg as a swiss army knife here
[09:01] <relaxed> I would file a feature request, https://trac.ffmpeg.org/
[09:02] <relaxed> you could use ffmpeg to decode any input and pipe to speexenc, though
[09:02] <mishehu> relaxed: first I'm going to see if my boss really wants me to pursue this.  I don't think it's very worthwhile unless we're doing a lot of transcoding
[09:03] <mishehu> and even then, speex and opus are tricky...   jmspeex says there *can* be a way to inject a raw speex or opus stream even though they're adaptive in realtime
[09:03] <mishehu> but I didn't get him to elaborate on that
[09:05] <mishehu> (and I don't think speexenc supports output to raw, only to speex-in-ogg...)
[09:06] <relaxed> the example I saw was, arecord -f S16_LE -c1 -r8000 -t raw | speexenc - --vad OUTPUT.SPX
[09:06] <relaxed> which appears to be raw speex
[09:08] <mishehu> .spx is generally considered to be speex-in-ogg
[09:08] <relaxed> ah, ok
[09:09] <mishehu> and when I test the output, it is indeed speex in ogg
[09:09] <mishehu> so no dice :-)
[09:10] <mishehu> fs_encode can do it but really I'd have to rework it so either I have an API interface to transcode with a running fs, or modify fs_encode to accept multiple file input/output
[10:07] <GT_> Hi guys, I would need a little advice. I'm trying to make a transition for image slideshow in ffmpeg with the following command: https://gist.github.com/anonymous/503c1005a91f5f2c6dae
[10:07] <GT_> my problem is that the result effect seems jittering
[10:07] <GT_> https://www.dropbox.com/s/9fk89kgdth6eb4c/output.mp4?dl=0
[10:08] <GT_> is there a way to make the movement smoother?
[10:08] <GT_> Any idea?
[10:10] <GT_> I would really need a handing help, if anybody got an idea would be awesome
[10:13] <relaxed> GT_: first thing would be to use a recent version of ffmpeg
[10:13] <relaxed> http://ffmpeg.zeranoe.com/builds/
[10:13] <GT_> Just a sec, downloading one. But would that matter that much?
[10:14] <relaxed> could be a bug that was already fixed
[10:15] <GT_> same result, should I re-post the new output?
[10:18] <GT_> here is the new command line with the new build: https://gist.github.com/anonymous/7cdab379eff97e3e4de7
[10:18] <relaxed> hmm, how can a static image look jittery?
[10:19] <GT_> I'm moving the image, and the movement is jittery
[10:19] <relaxed> (dropbox is blocked where I work)
[10:20] <GT_> hmm, just a sec, I upload it to youtube then
[10:20] <GT_> https://www.youtube.com/watch?v=VC9KEdLFU18&feature=youtu.be
[10:20] <relaxed> I've got to run for a bit. Lurk for a while and someone may help you before I get back.
[10:21] <GT_> Lurk? :) ok.
[10:21] <relaxed> hang out
[10:21] <GT_> Btw, this is the best result I could get when it's the same as the framerate, but if I do slower or faster, but not fast enough then it looks just terrible
[10:28] <GT_> Ok, I simplified a command to make sure it's about the overlay and not else making the jittering. This is the new command: https://gist.github.com/anonymous/541767d73bb4f518b5e0 and this is the new output: https://www.youtube.com/watch?v=3zjeH6_Fuk8&feature=youtu.be
[10:29] <GT_> if you look closer you can see that the image which is being moved jump forward and back slightly, which makes it look like jittering. Any idea?
[10:37] <GT_> One observation: if I slow it down even more, than I see that it can only jump it a whole pixel at a time, isn't there a way for it to interpolate it?
[11:25] <relaxed> GT_: do you notice it if you increase the fframerate?
[11:45] <GT_> just  asec let me try, I only increased to 30 fps for now
[11:46] <GT_> relaxed: It's noticable even at 60 fps
[11:47] <GT_> And as I said the problem is when I need to move it really slow it won't jitter, but jump whole pixels forward, which isn't really good. Is there any way to interpolate it?
[11:50] <GT_> relaxed: So is there any other way of doing this?
[11:54] <relaxed> Not that I know of. Maybe someone else will answer.
[11:56] <GT_> :(
[12:01] <GT_> Anyone have idea how could I use the overlay with some tipe of interpolation, so it wouldn't jump a whole frame at a time, but maybe interpolating the colors?
[12:21] <GT_> Any ffmpeg guru nearby? :)
[12:26] <hanshenrik_> GT_, try #ffmpeg
[12:26] <iive> hanshenrik_: this is #ffmpeg :P
[12:27] <hanshenrik_> so try here .p
[12:28] <GT_> iive: you're so funny :) let me paste my commands again
[12:28] <GT_> https://gist.github.com/anonymous/7cdab379eff97e3e4de7
[12:29] <GT_> https://www.youtube.com/watch?v=VC9KEdLFU18&feature=youtu.be
[12:29] <GT_> this is the output, if you watch closely you can see that the moving effect of overlay seems to be jittery any idea? @iive of fflogger
[12:29] <GT_> *or
[12:30] <GT_> iive: any idea, why it's jitteryng? And if I play it really slow it can only move 1 pixel, can't interpolate. So if I make the movement slower, it won't jitter, but jump pixel by pixel instead
[12:35] <GT_> hanshenrik_:  so funny man? :) Any idea why is my video jittering?
[12:37] <hanshenrik_> nope sorry
[12:38] <GT_> iive: And what about you?
[12:39] <iive> bgb
[12:47] <GT_> bgb?
[12:48] <iive> brb, sorry
[12:49] <iive> so, the problem is that the shift is 1 pixel every 2 frames
[12:49] <iive> instead of having 0.5 shift every frame.
[12:54] <GT_> for example yes
[12:55] <iive> from the cli, it looks like it should be moving one pixel at a frame...
[12:56] <GT_> But even if it would, it would be still noticable, is there any way to interpolate it?
[12:57] <iive> try moving the -r 25 to the start of the option list, just in case the input is somehow at 50 fps and then dropped down... or the opposite.
[12:57] <iive> GT_: i'm not an expert, c_14 seems to be more helpful, but I guess he is away atm.
[13:04] <GT_> same result, it seems ffmpeg overlay only works with whole numbers... and that's not good...
[13:04] <GT_> And I believe the jittery effect is because of rounding the numbers
[13:05] <GT_> I tried the same setup in after effects and there the pixels are interpolated, so the movement of the overlay seems smooth
[13:06] <GT_> I would need to achieve something similar in ffmpeg
[13:10] <iive> yeh, I also don't remember if eval does work with floats or integers. i thought it is integer only.
[13:11] <iive> ok, it uses floats
[13:12] <iive> the expression evaluation,
[13:12] <GT_> and what about overlay? Does it exepts float or it is rounded?
[13:12] <iive> let me check.
[13:13] <iive> but strangely if I do *50 then it goes one pixel per frame...
[13:13] <iive> t is supposed to be wall time...
[13:13] <GT_> wall time?
[13:16] <GT_> So is there any alrenative to use overlay with float numbers? Because it clearly rounds them up
[13:17] <iive> short for wall clock, aka real world clock, just saw something in the documentation.
[13:17] <iive> it doesn't seem to be problem with rounding. I added print(t) in the formula and I get:
[13:17] <iive> 7.966000
[13:17] <iive>     Last message repeated 1 times
[13:18] <iive> so it evaluates the formula twice using same t...
[13:18] <GT_> That's strange
[13:21] <GT_> Well if I'm not wrong, overlay filter uses int x, int y for overlay blending
[13:22] <GT_> At least if I'm checking in the right place xD https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_overlay.c
[13:24] <GT_> If I understand the source code correct, even if the eval returns a float number doesn't really matter. it is calling the  blend_image function afterwards, which accepts integer, so it is rounded up to the nearest int value...
[13:27] <GT_> iive: It seems I'm doomed :( If you have any idea how could I solve my problem would be nice
[13:28] <iive> well, you can cheat... you can upscale the image, blend it, then downscale it.
[13:29] <iive> it would be waste of cpu, but the video is short.
[13:29] <GT_> Yeah, not an option, because this is just a test
[13:29] <GT_> I would be rendering 2-3 minutes videos with these type of transition
[13:29] <GT_> and HD or fullHD resolution, so it means I would need to scale it up to QHD or 4K
[13:29] <GT_> which would just take eternity
[13:29] <iive> i think i've seen some functions with subpixel offsets, but I can't recall where.
[13:30] <iive> maybe font drawing.
[16:21] <DelphiWorld> yo
[16:21] <DelphiWorld> compile error
[16:21] <DelphiWorld> libavfilter/allfilters.c:179:1: error: CONFIG_PALETTEUSE_FILTER undeclared (first use in this function)
[16:21] <ubitux> run configure again
[16:22] <DelphiWorld> ubitux: ok, my dear
[16:24] <ubitux> that's the first thing written when you run make btw.
[16:26] <DelphiWorld> ubitux: lol i didnt see it
[16:45] <DelphiWorld> ubitux: mp2 audio is not lossless right?
[16:45] <ubitux> why asking me?
[16:45] <DelphiWorld> ubitux: just asked:P
[16:46] <ubitux> ffmpeg -codecs
[16:46] <ubitux> look at the top, then look for mp2
[16:46] <ubitux>  ....L. = Lossy compression
[16:46] <ubitux>  .....S = Lossless compression
[16:46] <DelphiWorld> ubitux: good and final answer
[16:46] <DelphiWorld> ubitux: so now i wont ask about lossy/lossless anymore
[16:47] <ramiro> since all systems are either lossy or lossless, does that mean you won't ask about anything anymore?
[16:48] <DelphiWorld> ramiro: lol
[19:56] <flaviocpontes> Hi.
[19:57] <flaviocpontes> Anyone can help me calculate the buffer size for CBR encoding of mpeg2 content?
[19:57] <flaviocpontes> I get buffer underruns all the time.
[19:58] <flaviocpontes> Guess the buffer is too big.
[22:52] <ThJ> so i've got what appears to be a misbehaving DSLR. anything i try to process with ffmpeg gets exaggerated contrast. it seems the camera is reporting 16-235 luma range but is actually outputting 0-255. i've been trying to override this somehow, using -pix_fmt and -color_range, but i can't see a difference in the output...
[22:54] <ThJ> it could be the other way around, not entirely clear on this point, but the camera is reporting yuvj420p and ffmpeg obeys that, and there's detail loss in the blacks...
[22:56] <ThJ> in any case, i can't really seem to find a way of telling ffmpeg to override that input format.
[23:03] <ThJ> hrm, it might be the decoders/players i'm using that are ignoring it...
[23:52] <c_14> ThJ: did you try overriding the in/out range with the in/out_range options in the scale filter?
[00:00] --- Sat Feb 21 2015