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

[burek]

[00:01] <relaxed> if that fails and you just to concat the streams, maybe mkvmerge would be a better tool.
[00:01] <relaxed> *just want to*
[12:58] <vvu|Log> can ffmpeg get video from DVD EZMaker 7 dongle ? as i know Linux has kernel support for it and it should see it as v4l device *think so*
[13:32] <DrSlony> Hi, I need to convert videos to divx/xvid because my dvd player only handles these old formats, whats the most compatible ffmpeg way to convert to that?
[13:34] <Katharsis> which of the software could you recommend me for screencast (not CLI based) recording?
[13:36] <Katharsis> we've used ffmpeg for last days
[13:36] <Katharsis> ffmpeg -f alsa -i pulse -f x11grab -r 30 -s 1366x768 -i :0.0 -vcodec libx264 -r 25 -preset ultrafast -threads 4 -y -sameq file_name.mp4
[13:38] <Katharsis> we can make and play mp4 file on Linux without any problems
[13:40] <Katharsis> Windows software play the movie without screen (voice only), the same problem is with Adobe Software
[13:42] <Katharsis> to fix it, we had to conver this ffmpeg mp4 movie into mp4 file type with FreeMake Video Converter
[13:42] <DrSlony> Katharsis recordmydesktop kazam istanbul vokoscreen vlc eidete tibesti byzanz
[13:42] <Katharsis> then, we realized that the sound isn't synch with video
[13:43] <DrSlony> Katharsis ive also had issues with windows people not being able to play mp4 made with ffmpeg in linux, but they upgraded their vlc or mplayer and it worked
[13:43] <Katharsis> DrSlony: which of them is universal for linux/windows and userfriendly?
[13:43] <DrSlony> most gui screen recording programs use ffmpeg anyway, so that probably wont work around the issue
[13:44] <DrSlony> Katharsis check each one's website for screenshots, see what you like
[14:36] <konflict> Hi, Im currently trying to solve -timecode sync issue. Im piping two SDI streams from BlackMagic Decklink  into ffmpeg to capture two DNXHD mxf files. I need to get identical timecodes on both clips based on either system time or some external source for later "frame precise" editing. So far I wasnt able to find any solution. Could anyone help?
[15:13] <Katharsis> DrSlony: we can't upgrade Adobe on Windows, it seems that v5 doesn't support libx264 + MP3 inside of MP4 file
[15:13] <Katharsis> any solution for this problem?
[15:24] <Trashlord> is there any option I can pass to possibly speed up the conversion time? I've spent the last 7 hours converting a 2 hour video file from a bunch of VOBs to an mp4 file
[15:27] <Trashlord> it's converting at 7.1 fps
[16:06] <Katharsis> is it possible to resize 1360x768 to 1280x720 without lost?
[16:06] <Katharsis> (mp4 movie)
[16:12] <Katharsis> i'm using ffmpeg -i movie_a.mp4 -s 1280x720 -acodec copy -sameq -sws_flags lanczos -f mpegts -vcodec libx264 -threads 0 movie_b.mpg for that
[16:12] <Katharsis> but i have a little lost (blur on strings)
[16:16] <saste> Katharsis, no
[17:19] <ac_slater> hey guys, I'm pretty new the world of video encoding/decoding/containers. I'm trying to find the best container/format for nice balance of file size and enc/decode complexity. I'll be creating these containers for use on an embedded system, hence the avoidance of h.264. Any suggestions?
[17:19] <ac_slater> (also, I dont care about audio right now)
[17:20] <ac_slater> (and i know h.264 is awesome and all, I just do not have access to hardware encoder)
[17:21] <klaxa> try xvid/mpeg4 part 2
[17:21] <klaxa> also, that's a codec, not a container
[17:21] <ac_slater> klaxa: right, I understand that much ;)
[17:21] <klaxa> container would be matroska or avi or mp4
[17:21] <ac_slater> is there a comparison matrix for popular containers?
[17:22] <klaxa> http://en.wikipedia.org/wiki/Comparison_of_container_formats
[17:22] <ac_slater> haha
[17:22] <ac_slater> klaxa: apologies mate.
[17:23] <klaxa> huh? why?
[17:23] <ac_slater> didn't do my googling before bothering people here
[17:24] <ac_slater> (other channels I'm on HATE that)
[17:24] <klaxa> well usually yes
[17:25] <ac_slater> aside from xvid / mpeg4pt2, any other suggestions?
[17:25] <klaxa> if xvid is still too complex maybe mpeg2
[17:25] <klaxa> if that is too complex i hope the databus is fast enough for rawvideo
[17:26] <klaxa> http://en.wikipedia.org/wiki/Comparison_of_video_codecs here's another hopefully helpful list/comparison
[17:26] <ac_slater> klaxa: in my case, I *can* do raw video, but there might be mixins with streaming protocols later - like RTSP which have certain codec restrictions
[17:26] <ac_slater> yea I just saw that link ... sadly a lot of stuff on there is "unknown"
[17:27] <ac_slater> oh but that's just software support - nevermind
[17:27] <klaxa> well what are the specs of the device?
[17:27] <ac_slater> 1Ghz dual-core ARM cortex A9 SoC
[17:27] <klaxa> doing video decoding on embedded devices without hardware decoding is pretty... eh i guess
[17:27] <klaxa> oh that should be able to handle xvid just fine
[17:28] <ac_slater> klaxa: yea I think so as well, it just sucks bad at encoding h.264
[17:28] <klaxa> or mpeg 4 part 2
[17:28] <klaxa> i think xvid is even mpeg 4 part 2 compliant
[17:28] <klaxa> let me check
[17:29] <klaxa> >Xvid (formerly "XviD") is a video codec library following the MPEG-4 standard, specifically MPEG-4 Part 2 Advanced Simple Profile (ASP).
[17:29] <klaxa> at least wikipedia says so
[17:29] <ac_slater> badass.
[17:33] <ac_slater> klaxa: by any chance, do you know much about RTSP ?
[17:33] <klaxa> actually not
[17:33] <ac_slater> ah thanks anyways. It seems to be a difficult topic to get some solid details on
[17:34] <klaxa> i tried to get into video streaming with ffserver, but i didn't get how it worked so i kinda gave up and settled for setting myself a goal of writing a proper streaming server for matroska over http
[17:34] <klaxa> no idea when that will take off though
[17:35] <ac_slater> klaxa: that's pretty awesome. I'd be interested in taking a look at that if it's opensource - mostly cause I have no idea what streamers have to manage in terms of packetization. Sadly, I have to keep my protocols standardized.
[17:35] <klaxa> haven't seen any streaming software that supports matroska for streaming so far, i don't even know why, it's designed for live-streaming and the most sophisticated container format available
[17:36] <klaxa> well http is pretty standardized
[17:36] <klaxa> i have some other projects still open, i want to finish those first, yesterday i finally managed to compile libmatroska2
[17:37] <klaxa> i'll probably go through the source and try to jot down *some* sort of documentation
[17:37] <klaxa> there is neither documented how to compile it, nor how to use it, lol
[17:37] <ac_slater> klaxa: typical ;)
[17:37] <klaxa> i've heard the same thing about libmatroska
[17:38] <klaxa> "Well... if you need documentation, maybe read the vlc source..."
[17:38] <ac_slater> I've streamed mkv containers in the past though. Maybe they were being transcoded or something
[17:38] <klaxa> how did you do that?
[17:38] <ac_slater> yea, I don't like that indirection either - producing documentation isnt too difficult
[17:39] <klaxa> but it's not as much fun as coding the thing in the first place :)
[17:39] <ac_slater> klaxa: recently, I used `rygel` to broadcast some mkv files via DLNA.
[17:39] <klaxa> i can relate, i'm not fond of writing documentation, but reading documentation is greatly appreciated
[17:39] <ac_slater> (not sure what implications lay in the DLNA/UPnP method though)
[17:40] <ac_slater> writing docs help me produce usable interfaces ;)
[17:40] <klaxa> hmm yeah i haven't dealt with DLNA either
[17:40] <klaxa> but i don't think it's actually the sort of live-streaming i want to achieve
[17:40] <ac_slater> klaxa: but http is much more convenient anyways
[17:45] <ac_slater> man, stepping into the world of video enc/dec/containers is overwhelming.
[17:47] <klaxa> well at least you are already starting with ffmpeg
[17:47] <klaxa> that's good because it's the de-facto open-source standard
[17:47] <klaxa> most open-source video projects have ffmpeg or its libraries as dependencies
[17:48] <ac_slater> right, I've been using it for years as a converter,etc ... but never as an SDK
[17:48] <klaxa> ah, well yeah i haven't looked into the libraries either really...
[17:48] <klaxa> i'd much rather have some nice python bindings than writing everything in C :x
[17:49] <ac_slater> klaxa: haha yea I second that. It would make prototyping faster anyways
[18:12] <lnostdal> so, "compilation; it just takes a few minutes" says the wiki ..   but then why aren't there any up to date, official ppa for ubuntu (yes; for the masses and the noobs) out there which is up to date in the same way the ppa for e.g. vlc is up to date?
[18:13] <lnostdal> instead, the masses end up with libav.....    unfortunate
[18:18] <klaxa> good question, i just compile from source :x
[18:18] <klaxa> or get a static build
[18:19] <klaxa> which are up to date
[18:21] <lnostdal> yeah, the static build (well one of them; i did not test both of them) doesn't include pulseaudio (or alsa; i'm not sure) support ..    x11grab support is also missing
[18:22] <lnostdal> that's the two things i know are missing; perhaps more things are missing too
[18:22] <klaxa> true, i think x11grab is not possible with static binaries
[18:22] <Mavrik> yeah, because they're system dependant
[18:22] <klaxa> well feel free to set it up yourself if you feel that it's missing :I
[18:22] <Mavrik> also, making a PPA for ffmpeg is PITA
[18:22] <klaxa> that's what linux lives off after all
[18:22] <Mavrik> due to wierd Debian rules for building debian packages
[18:25] <JEEB> I think in general there's less weird rules and more that you can't make a package that provides the basic libraries that has a different API/ABI. So I think you're left with 1.xx ffmpeg if I recall correctly. Might have been pushed further because the libav 9 migration has finally finished. They're now doing libav 10 migration to be ready for its release so you should then be able to package newest ffmpeg as well
[18:25] <JEEB> it's kind of sad to look at the migration status when someone is trying to update X amount of downstream projects by himself
[18:25] <JEEB> something you don't think about at all when you just use the ffmpeg command line app
[18:26] <lnostdal> yeah, i can compile this from source myself ..   i've done so many times ..    or i can go grab up to date .deb from some semi(?) dodgy ppa (e.g. https://launchpad.net/~samrog131/+archive/ppa ) ..   *shrug*
[18:36] <lnostdal> even with ABI / API problems - some official ppa for ffmpeg that states that "this will or might cause problems" (because of API / ABI changes) would be great ..    it doesn't have to be "perfect"; something official would already be better than the alternative ways (unofficial ppa or from source) ..     perhaps the packages and executables could have different names ..    anyway, just rambling; i'll go back to compiling this now .. :P
[18:39] <beastd> lnostdal: I agree that we would be better off with some .deb package
[18:39] <beastd> but thing are never easy :8
[18:39] <beastd> :(
[18:40] <beastd> a .deb delivering static only binaries (and libs maybe) should be OK
[18:41] <JEEB> libs can kind of lead to unforeseen consequences unless you really work it out
[18:41] <JEEB> ffmpeg/-probe/-play can be built with static libav* of course
[18:41] <JEEB> which could be packaged
[18:41] <beastd> anything that delivers dynamic libs, will cause problems
[18:42] <JEEB> even static
[18:42] <beastd> and even worse the problems will most likely end up in the wrong mailbox :(((
[18:42] <beastd> *the problem reports
[18:43] <JEEB> anyways, most people just want the tools
[18:43] <JEEB> which I guess isn't that hard to deliver
[18:43] <JEEB> even if they would go against official debian policies (static linking)
[18:43] <beastd> JEEB: What scnenario do you have in mind where static libs would cause problems? (just curious)
[18:43] <JEEB> just means it wouldn't get into mainline
[18:43] <JEEB> beastd, if they are put into the search path basically
[18:43] <JEEB> so you have libav's shared libs
[18:43] <JEEB> and ffmpeg's static ones
[18:44] <JEEB> linker's search path of course is what I mean
[18:44] <JEEB> there are ways around this of course
[18:46] <beastd> JEEB: that is only a problem when building stuff and you do not want to use current FFmpeg (e.g. a project that only works with Libav or older versions of FFmpeg), right?
[18:46] <JEEB> well, it's always a problem depending on which the linker happens to pick
[18:46] <JEEB> and which you wanted
[18:47] <JEEB> just means that if you want to package libraries you'll probably want to do it in some way that won't make the distro's stuff overlap
[18:47] <JEEB> and headers
[18:47] <beastd> yeah, probably
[22:12] <CoJaBo> I have a bunch of 3GP files where the "moov atom" is missing; is there any hope of recovery whatsoever, or should I just delete them?
[22:12] <haarp> when ffmpeg cant know the duration of any of the input streams (http://pastebin.com/Li3dHQk8  -1-), the stats shown during operation are completely wrong. the time count up way faster than realtime, even though it can only capture in realtime. when i add a duration to the audio (-2-), the stats are correct again. whats going on?
[22:24] <konflict> Hi, Im currently trying to solve -timecode sync issue. Im piping two SDI streams from BlackMagic Decklink  into ffmpeg to capture two DNXHD mxf files. I need to get identical timecodes on both clips based on either system time or some external source for later "frame precise" editing. So far I wasnt able to find any solution. Could anyone help?
[23:52] <BeWilled> Is there a parameter to tell ffmpeg to overwrite everything and don't ask?
[23:53] <haarp> -y
[23:53] <relaxed> BeWilled: ... -y output_name
[00:00] --- Sun Jan  5 2014