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

[burek]

[00:22] <bryancp> Hello, av_read_frame is always giving me a packet size of 1024, no matter what I define pkt_size to be in the options to avformat_open_input. Any clues?
[00:23] <Mavrik> um, you get packets in size of what your input has
[00:23] <Mavrik> or what your decoder produces.
[00:25] <bryancp> Mavrik: input is u-law, 160 every 20ms
[00:27] <bryancp> heres how I open input: avformat_open_input(&pFormatCtx, url, av_find_input_format("mulaw"), &opts)
[00:28] <Mavrik> you perhaps didn't understand what I said
[00:29] <Mavrik> your solution is "deal with it".
[00:29] <Mavrik> (or patch the demuxer/decoder)
[00:30] <bryancp> yay glad theres so much control built in
[06:07] <theekoz> Is there a ffmbc channel?
[06:07] <c_14> #ffmbc
[06:10] <theekoz> And am I abot to set pmt's and video pids in ffmpeg or only in ffmbc for a ts with h264/avc ac-3 embedded?   Any updates on CEA-608 or CEA-708 caption integration happening on either platform or is it only on OBE?
[07:02] <theekoz> If I have a .ts file with 1 Video track and 1 Subtitle CEA 608 track.. can FFMBC or FFMPEG Remux it so I can add in the matching audio track from my MP4 Source file?
[10:40] <relaxed> theekoz: most likely
[10:41] <relaxed> ffmpeg -i input.ts -i input.mp4 -map 0:v -map 0:s -map 0:a -c copy output.ts
[10:42] <relaxed> sorry, that should be  ->  ffmpeg -i input.ts -i input.mp4 -map 0:v -map 0:s -map 1:a -c copy output.ts
[10:44] <theekoz> thanks relaxed. Is it okay is the input.mp4 is the ac3 file?  the .ts I have from OBE has video stream and CEA 608 embedded.. adding ac3 in ffmbc so I don't get a 11 second audio delay like in OBE.. instead just get a 1.4 which is acceptable.
[10:45] <theekoz> I just want to keep the -ts-video-pid -ts-pcr-pid -ts-pmt-pid -ts-cbr and muxrate headings ideally because most of them I haven't been able to find the ffmpeg/ffmbc equivilent to. Need them with the TS so just want to embed the audio track while leaving the rest of the ts in tact
[10:51] <theekoz> Getting a: Stream map '0:s' matches no streams. error from the last string you just setn relaxed and mapping confuses me.. not quite sure what's up. I'll keep messing with it.
[11:09] <relaxed> pastebin.com the command and output
[15:12] <DelphiWorld> hi ffmpegsters;)
[15:12] <DelphiWorld> if i convert my medias to AAC
[15:13] <DelphiWorld> a issue
[15:13] <DelphiWorld> bitrate is not always exact, its may be up or down
[15:13] <DelphiWorld> i chouse 64kbit/s but its 67kbit/s
[15:13] <DelphiWorld> any idea?
[15:35] <ubitux> container overhead?
[15:35] <ubitux> also depends on the codec used
[15:36] <DelphiWorld> ubitux: m4a, aac
[15:36] <ubitux> there are multiple aac encoder
[15:36] <ubitux> m4a is the container
[15:36] <DelphiWorld> ubitux: native
[16:20] <Guest26937> what does "mb_block_count" variable contain if mpeg encoders and decoders?
[16:33] <theekoz> anyone know how to null pad with empty bits a ts with ffmpeg of ffmbc? need continuous bitrate of 5480 and my stream right now is at 4512
[16:33] <JEEB> I thought the mpeg-ts muxer had VBV options?
[16:34] <JEEB> although if you want proper muxing I recommend you mux your streams with something like OBS's muxer
[16:34] <JEEB> https://github.com/kierank/libmpegts
[16:35] <JEEB> (and it was OBE not OBS, sorry)
[16:35] <DelphiWorld> OBE?
[16:36] <DelphiWorld> open broadcast encoder?
[16:36] <JEEB> yes
[16:36] <DelphiWorld> and OBS?
[16:36] <DelphiWorld> what is OBS
[16:36] <JEEB> OBS is some screen capture thing / streamer :P
[16:36] <DelphiWorld> JEEB: dude
[16:36] <DelphiWorld> do you know MBC?
[16:36] <DelphiWorld> a playout system
[16:37] <DelphiWorld> my CPU will start crying soon
[16:37] <JEEB> no
[16:37] <DelphiWorld> JEEB: i'm looking for a tv scheduler
[16:38] <JEEB> and I don't give a damn :P
[16:38] <DelphiWorld> JEEB: lol
[17:17] <adsisco> how can i embed a video into another video?
[17:32] <c_14> adsisco: Do you want something like the overlay filter?
[17:35] <myfree> how can I concatenate mp4 files on the command line with ffmpeg?
[17:35] <c_14> myfree: https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20(join,%20merge)%20media%20files
[17:36] <DelphiWorld> c_14: ^_^
[17:40] <adsisco> c_14 whats an overlay filter? someone in gstreamer channel mentioned video mixer
[17:40] <adsisco> are they are same thing?
[17:45] <c_14> The overlay filter will take a video or image and overlay it on another video or picture.
[17:46] <adsisco> yup, something like that. I'll have video A playing, and video B playing in a small box at the corner
[17:47] <c_14> https://ffmpeg.org/ffmpeg-filters.html#overlay-1
[17:48] <adsisco> c_14 thanks, i'll look into it
[17:55] <theekoz> Have you tried MBC DelphiWorld? Did you find the download link? It's web based right..
[17:56] <theekoz> And thanks to everyone for their help.. got it all working with an OBE FFMPEG Combo
[18:53] <DelphiWorld> theekoz: lol, its complicated
[19:08] <lkiesow> Hi, I'm still trying to cut some videos in several parts and rearrange them. While it now works in general, I get some errors like  [Parsed_concat_24 @ 0x2e33ac0] Buffer queue overflow, dropping.rate=2030.2kbits/s
[19:08] <lkiesow> What I'm doing is basically a complex filter with several (a)trim filters to get the right parts, then use a concat filter to put them together again
[19:08] <lkiesow> Here is, what I'm doing: http://fpaste.org/106158/55547514/
[19:08] <lkiesow> Does anyone have an idea what's going wrong?
[19:08] <lkiesow> The resulting video looks ok at first but at one time stops playing
[19:10] <lkiesow> I've also tried to split the audio and video filters with the same result
[19:43] <lkiesow> What is interesting is that if use -ss and read the same files multiple times (then use trim=0:length ...) works: http://fpaste.org/106168/15581211/
[19:44] <lkiesow> So my guess is that keeping too many party of the same file in memory causes the problems
[20:06] <hxla> Hello, I'm trying to burn-in a subtitle to a mp4 using a raspberry pi, it works, but the performance is terrible, around 3-6 fps... it's not using raspberry pi GPU, is there a way or filter to use it's GPU? Thanks
[20:08] <ubitux> ask clever
[20:08] <ubitux> he was working on this, but no news from him
[20:09] <hxla> thanks, I'll send him a msg
[20:49] <shevy> hi
[20:50] <shevy> I use this to capture my screen:
[20:50] <shevy>   ffmpeg -f x11grab -video_size 1024x800 -r 25 -i :0.0 /Depot/Temp/GRABBED_X11.mpg
[20:50] <shevy> Anyone has some advice whether this is good or bad? I suppose storing into .mpg isn't ideal but I am unsure what useful alternatives to pick
[21:02] <Demitar> shevy, it all depends on your needs and resources. Storing it in a lossy format might not be good if you want to process it a lot down the line at the same time you do want some kind of compression unless you have a huge disk to spare. I'd say experiment a bit to make sure you have an acceptable size/quality ratio (and also the formats are useable in whatever application you intend to process them with later). I've been toying a bit w
[21:02] <shevy> hmm
[21:03] <shevy> yeah, the quality is quite awful so far
[21:03] <Demitar> That's going to bite you once you want to start editing the material.
[21:04] <Demitar> You might be better off recording just part of the screen or specific windows to keep the filesizes at bay.
[21:15] <Demitar> Anyone tested gdigrab, I seem to be getting severe aliasing issues on anything which has color. (Which is rather odd since it's grabbing from a crisp terminal.)
[21:17] <Demitar> I seem to be getting the same issue capturing desktop through the dshow desktop "video drivers", but for instance Open Broadcaster Software and ffsplit capture the windows and desktop perfectly.
[22:35] <UtUser> Are there libav binaries for OSX and Linux out there?
[22:36] <c_14> For libav support se #libav
[22:36] <c_14> *see
[22:36] <UtUser> oh ok
[22:36] <UtUser> BTW is it used in ffmpeg?
[22:36] <UtUser> I mean as a dylib
[22:36] <JEEB> libavcodec/-format and other libav* libraries are something provided by both libav and ffmpeg
[22:37] <UtUser> oh hello JEEB
[22:37] <JEEB> basically, by saying "libav binaries" you are meaning "Binaries of the executables/libraries from the Libav project"
[22:37] <JEEB> probably not what you mean :P
[22:37] <UtUser> well, specifically the libraries
[22:38] <JEEB> yes, call them libav* or separately lavc/lavc etc.
[22:38] <JEEB> libav means the project and is never used to mean libav*
[22:38] <UtUser> what difference does the asterisk mean?
[22:39] <JEEB> it means that something comes after it
[22:39] <UtUser> oh ok
[22:39] <UtUser> so likelibavcodec?
[22:39] <JEEB> because most of the libraries start with [lib]avSOMETHING
[22:39] <JEEB> yes
[22:39] <JEEB> libavcodec (lavc), libavformat (lavf) etc
[22:39] <UtUser> I see
[22:40] <UtUser> I was just hoping to pick up some .so's to go with some .dll's and dump them in a folder somewhere for use with murgaLua/LuaJIT
[22:41] <UtUser> but anyhow
[22:41] <JEEB> http://ffmpeg.org/download.html
[22:41] <JEEB> has some links to some binaries
[22:41] <JEEB> although you'd also need matching headers, but that you can get from the git repo
[22:42] <UtUser> there's no OSX build
[22:42] <UtUser> I mean
[22:42] <UtUser> there's a static build but no dynamic
[22:42] <JEEB> unsurprising
[22:42] <JEEB> since most people just need the ffmpeg binary
[22:43] <JEEB> that said, it's not like it's hard to build ffmpeg on OS X, esp. if you have the basic tools around
[22:43] <UtUser> thing is, I'm targeting both Linux and OSX but plan to est on neither
[22:43] <UtUser> *test
[22:44] <JEEB> then make your thing and then ask someone to test :P
[22:44] <UtUser> well I suppose but they'd also need to know how to compile stuff, and that could be tricky
[22:45] <UtUser> of course, just piping to the ffmpeg binary might be easier because it's more ubiquitous
[22:45] <UtUser> but I hear it's quite slow
[22:45] <UtUser> like, you can't really scrub through a video clip that way
[22:45] <JEEB> dunno, unless you're doing something weird it shouldn't be any slower
[22:45] <JEEB> also, well, generally if something is found useful someone will come test it :P
[22:46] <JEEB> esp. if you note you're looking for people capable of handling it
[22:46] <UtUser> I'm not terribly concerned with the testing part
[22:46] <JEEB> + OS X has stuff like homebrew
[22:46] <UtUser> a package manager?
[22:46] <JEEB> which will help people get most of the dependencies
[22:46] <JEEB> yeah
[22:46] <UtUser> well sure
[22:46] <UtUser> but I mean
[22:46] <UtUser> everyone has ffmpeg
[22:47] <UtUser> you can even get it on Android now
[22:47] <UtUser> so using the executable as a backend is an option I suppose
[22:47] <UtUser> but IDK how to get a picture to display in my window straight out of a video
[22:48] <UtUser> other than saving it somewhere, which greatly increases latency
[22:49] <UtUser> not sure if FFMPEG can put it in a memory buffer
[22:49] <JEEB> I can definitely see ways to do that with both the library and the command line app, but I'm not really going to poke you either way :P Because I have no idea about the use case etc.
[22:49] <UtUser> ok
[22:49] <UtUser> well, I have this great idea for a video editor
[22:49] <UtUser> and sufficien programming experience
[22:50] <JEEB> ah
[22:50] <UtUser> so that's basically it
[22:50] <JEEB> do note that you will have real fun with frame-exact access
[22:50] <UtUser> I know
[22:50] <JEEB> I recommend looking into stuff like ffms2 or L-SMASH Works for that
[22:50] <JEEB> they are wrappers around lavf/lavc that try to give that out
[22:50] <UtUser> cool
[22:51] <JEEB> ffms2 has a C API, L-SMASH Works still doesn't have such, but it is much better with interlaced stuff f.ex.
[22:51] <UtUser> I don't know how a library couldn't have a C API of some sort
[22:51] <JEEB> well yeah
[22:52] <JEEB> L-SMASH works has plugins for vapoursynth/avisynth/aviutl
[22:52] <JEEB> no generic one
[22:52] <JEEB> while ffms2 has a generic one
[22:52] <UtUser> I see
[22:52] <JEEB> https://github.com/FFMS/ffms2 , https://github.com/VFR-maniac/L-SMASH-Works/
[22:53] <JEEB> one could of course port the useful interlacism etc. related things from L-SMASH Works to ffms2
[22:53] <JEEB> or a generic API could be made to L-SMASH Works
[22:53] <UtUser> the basic FFMPEG deals with interlacing in what I consider an acceptable way
[22:54] <JEEB> the problem comes when you try to handle it frame-exactly and with seeking
[22:54] <UtUser> oh
[22:54] <JEEB> basically, lavf/lavc are VERY good with A->B stuff
[22:54] <JEEB> seeking to parts of things is better now, but will in many cases not be frame exact
[22:54] <UtUser> I see
[22:55] <JEEB> thus I recommend that you try to work with such a wrapper project in case of frame exactness being important
[22:55] <JEEB> (which kind of is with a video editor)
[22:55] <UtUser> itis pretty important yeah
[22:55] <JEEB> you can try out Aegisub (a subtitle editor) as an app that uses ffms2
[22:55] <JEEB> it uses it for the video and audio loading from the video
[22:56] <UtUser> cool
[22:56] <JEEB> http://www.aegisub.org/
[22:56] <JEEB> https://github.com/Aegisub/Aegisub/
[22:56] <UtUser> there's no Linux build
[22:57] <JEEB> they tried to provide an ubuntu package for a while, but I think they just gave up regarding that officially
[22:58] <JEEB> debian/ubuntu does seem to have aegisub in the repos, but not sure if it's 3.x
[22:58] <UtUser> hmm
[22:58] <UtUser> well, it would be important to have thesame version of libav* across platforms
[22:59] <UtUser> assuming it's not a static link
[22:59] <JEEB> on lunix that pretty much falls apart unless you provide the binaries yourself either as separate packages or in the same one
[23:00] <JEEB> because you end up being left with the stuff in the given distro's given version
[23:00] <UtUser> I don't see what you mean
[23:00] <JEEB> well, on lunix you generally use the things packaged in the distro if only possible
[23:00] <UtUser> any .so's in the folder with your executable will override the system liraries
[23:00] <JEEB> while elsewhere you generally build the libraries and provide them with your binary
[23:00] <UtUser> conventions suck
[23:01] <JEEB> that holds true with windows because PATH includes dot
[23:01] <JEEB> on lunix you'd have to play with LD_LIBRARY_PATH
[23:01] <JEEB> because dot most definitely is not there in the default library loading path
[23:01] <UtUser> then you simply rename the library binaries to something else
[23:01] <UtUser> like libavc_bundled
[23:02] <UtUser> problem solved
[23:02] <JEEB> uhh, you're pretty much saying what I was noting :P
[23:02] <JEEB> that idea of having the same version everywhere either falls apart (you follow conventions), or you provide the library yourself
[23:03] <UtUser> I see
[23:03] <UtUser> but I mean
[23:03] <beekar> my gentoo had it, i just had to figure out what options to build it with.
[23:03] <JEEB> beekar, that's a separate problem
[23:03] <beekar> like i missed 'rtmp' and couldnt figure out why my shat wouldn't work.
[23:04] <beekar> not a problem, just a comment.
[23:04] <JEEB> basically this guy wants to have the same exact version of the libraries for all users of his thingamajig
[23:04] <UtUser> whether or not that is necessary depends on the library I guess
[23:05] <UtUser> I just want it to work
[23:05] <JEEB> don't worry, you'll always have problems
[23:05] <UtUser> heh
[23:05] <beekar> huh.  not sure i've seen that.  i guess some programs do have version restrictions.
[23:05] <JEEB> the better side of things at least is that ffms2's API hasn't changed for quite a while
[23:05] <UtUser> I'm glad you are so familiar with it
[23:06] <JEEB> the libav* APIs have changed that it uses, but at least you shouldn't have too much of a problem dealing with various versions of ffms2
[23:06] <UtUser> so for example ffms2_32.dll
[23:06] <JEEB> that said, you will _always_ have issues with people having various versions of libav* in the background, that's just something you can't avoid
[23:06] <UtUser> oh whoah
[23:06] <UtUser> so you're saying to not even distribute libav?
[23:07] <UtUser> tell people to download it themselves?
[23:07] <JEEB> uhh
[23:07] <JEEB> not really
[23:07] <JEEB> follow the conventions of a given platform
[23:07] <UtUser> does ffms2 include libav* statically?
[23:08] <JEEB> the builds that aegisub distributes, yes
[23:08] <UtUser> cool
[23:08] <UtUser> and I assume third-party Linux aegisub builds too
[23:08] <UtUser> and there's this other dll in here
[23:08] <UtUser> avisynth.dll
[23:09] <UtUser> I assume that's just for effects
[23:09] <JEEB> it's for loading avisynth scripts :P
[23:09] <UtUser> I see
[23:09] <JEEB> also no, with lunix you use what the system has
[23:09] <JEEB> most distributions have some sort of libav* and ffms2
[23:10] <UtUser> ffms2 as wel?
[23:10] <JEEB> yes
[23:10] <JEEB> debian has it, ubuntu has it, I'm pretty sure a whole lot of other distros have it too
[23:10] <UtUser> so like when you install puppy linux for the first time it's gonna come with libav* and ffms2?
[23:10] <UtUser> the package manager is sort of another stry
[23:10] <UtUser> I mean, libav* is ubiquitous enough
[23:11] <UtUser> not sure about ffms2
[23:11] <JEEB> your application would be an extra package anyways :P
[23:11] <UtUser> yeah
[23:11] <JEEB> anyways, I have NFI about puppy linux
[23:11] <JEEB> depends completely on what it bases upon etc
[23:11] <UtUser> yeah
[23:12] <UtUser> so you're saying that as long as I'm referencing ffms2 I'm safe
[23:12] <JEEB> all that I'm saying is that a lot of distros have both libav* and ffms2 available in the standard repositories
[23:12] <JEEB> well, you're safe in the way that the API doesn't change a lot
[23:12] <JEEB> since it's a wrapper
[23:12] <UtUser> that's good
[23:12] <JEEB> so you don't have to deal with the various versions of Libav and FFmpeg yourself
[23:13] <UtUser> that's very good
[23:13] <JEEB> other than dealing with the fact that the various versions can give different results of course, but that problem you'd have anyways :P
[23:13] <UtUser> yeah
[23:13] <UtUser> fucking utvideo
[23:13] <JEEB> (unless you provide binaries yourself and force those to be loaded instead of system ones on every system)
[23:14] <UtUser> that would be a challenge with this choice of libraries though
[23:15] <UtUser> I'd at least have the same Windows and Mac libraries since they're from the same source
[23:15] <UtUser> Linux users are sort of on their own
[23:17] <JEEB> so what happened with the ut video case, btw :P
[23:17] <UtUser> not liking that 10.7+ only compatibility
[23:18] <UtUser> well, with utvideo
[23:18] <UtUser> some guy named Carl submitted a patch
[23:18] <UtUser> it's supposed to fix it but it's largely untested
[23:18] <UtUser> so it may get accepted
[23:19] <JEEB> yes, which was a couple of days ago with an unanswered question of "does a file encoded with the lavc encoder and breaking decoding actually decode fine with the official decoder?"
[23:19] <UtUser> meanwhile I re-opened the ticket since it seems to be universally agreed-upon now that the decoder is brken
[23:19] <UtUser> well, I did some testing
[23:19] <UtUser> I think you asked me also if it was a threading thing
[23:19] <JEEB> no
[23:19] <JEEB> I asked about slices
[23:20] <UtUser> slices
[23:20] <UtUser> so I transcoded to utvideo with 1 slice
[23:20] <UtUser> and I got the same problem
[23:20] <JEEB> ok
[23:20] <UtUser> so I imported the clip into VirtualDub and it played fine
[23:20] <JEEB> can you give me a sample that, when encoded with my utvideo encoder, replicates the issue?
[23:21] <UtUser> sure 1 sec
[23:21] <JEEB> so I can play with it and make some things sure
[23:22] <UtUser> uploading now - BTW I assume you mean the 1-slice clip
[23:23] <JEEB> I mean some clip that when encoded as ut video with my encoder shows the problem when decoding
[23:23] <JEEB> so I can test the whole chain
[23:23] <UtUser> sure
[23:23] <JEEB> input->encoder->decoder
[23:23] <UtUser> oh
[23:23] <JEEB> you give me the input, and I handle the rest :P
[23:23] <UtUser> yeah, well I'm not sure if that's possible
[23:24] <JEEB> well that makes making sure that the decoding after encoding is bit-exact kind of impossible :P
[23:24] <JEEB> if I don't know how the source was supposed to be
[23:24] <UtUser> yeah
[23:24] <UtUser> hmm
[23:24] <UtUser> well, you'd probably be better at that than me
[23:25] <UtUser> I just take any old 1920x1080 video clip
[23:25] <JEEB> well the problem is that exact case of "any"
[23:25] <UtUser> encode it as utvideo then decode it as something else
[23:25] <JEEB> because it might not really be "any"
[23:25] <UtUser> it's on a frame-by-frame basis, right?
[23:25] <UtUser> these clips come from a camera
[23:26] <le_tropico> what delay should be set in imagemick's "convert - delay" option if I've extracted frames from video with ffmpeg -r 29.97? I want to create gif with proper framerate
[23:26] <UtUser> the problems pop up all too often
[23:26] <JEEB> well "too often" is still not "always"
[23:26] <JEEB> if I just want to focus on getting shit fixed
[23:26] <JEEB> I want a sample I can just give the encoder and have it happen
[23:26] <UtUser> yeah I understand
[23:26] <UtUser> I'll work on it
[23:26] <JEEB> k
[23:26] <JEEB> thanks
[23:26] <UtUser> np
[23:27] <JEEB> if I confirm certain things, I will then reply on that mailing list thread
[23:28] <c_14> le_tropico: try .03337
[23:29] <UtUser> itwould be an honor
[23:29] <le_tropico> c_14, thanks, I'll check it
[23:37] <le_tropico> c_14, it's too slow. I've tried with .337 but it slow too, than with 3.37 and it seems a little bit quicker
[23:37] <c_14> 29.97 frames per second should be .03337 seconds per frame
[23:48] <UtUser> there we go - breaker.avi
[23:48] <UtUser> http://www3.zippyshare.com/v/71187664/file.html
[23:49] <JEEB> lessee
[23:53] <UtUser> I transcode to rgb24 utvideo BTW
[23:53] <UtUser> not sure if the probems come up with other colorspaces on this clip
[23:54] <JEEB> I'll compile ffmpeg either tonight or tomorrow, and check things
[23:58] <UtUser> okey dokey
[00:00] --- Sun Jun  1 2014