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

burek burek021 at gmail.com
Sat May 10 02:05:01 CEST 2014


[00:06] <kolizer> a -ss use? c_14
[00:11] <c_14> -ss is usually only helpful when you don't want part of the input, not when the a/v is out of sync
[00:13] <kolizer> Show an example of how to use -itsoffset ? c_14
[00:15] <c_14> ffmpeg -i audio.mp3 -itsoffset 25 -i video.mp4 output.mp4
[05:44] <allengreen> I use "ffmpeg -i input_file.mp4 -vcodec copy -an output_file.mp4" to remove audio track from mp4,  but that does not keep the frame pts, anybody know how to do this?
[05:54] <Bray90820> So i seem to be getting a strange error while converting a vob to flac on ubuntu
[05:54] <Bray90820> http://pastebin.com/w9ySbLZH
[05:55] <Bray90820> Here is the raw text which is easier to read
[05:56] <Bray90820> http://pastebin.com/raw.php?i=w9ySbLZH
[10:24] <anshul> !log
[11:33] <kolizer> Picture with a web cam behind the video screen http://pastebin.com/SRUqapCP
[11:35] <kolizer> how to fix?
[11:46] <kolizer> help
[11:48] <xagaba> I'm using FFplay version SVN-r0.5.10-4:0.5.10-1 that states --enable-vdpau in configuration. How I can tell ffplay to use vdpau for playback ?
[11:49] <JEEB> it's not implemented in ffmpeg or ffplay (esp. at such an old version), not sure if supports it even now
[11:49] <JEEB> also man, that is an old version :D
[11:51] <xagaba> it's squeeze version..
[11:52] <xagaba> but the configuration shows that vdapu it's enabled ....
[11:52] <JEEB> yes, it probably has some kind of vdpau support in libavcodec
[11:52] <JEEB> that does NOT mean it can be just used from ffmpeg or ffplay
[11:53] <JEEB> hw accels generally need a framework around them
[11:53] <xagaba> using  squeeze mplayer i can use vdpau, don't mplayer use ffmpeg libs ?
[11:54] <JEEB> yes, they use the hwaccel, so they have the surrounding code there
[11:54] <JEEB> ffmpeg and ffplay haven't had it before late 2013
[11:54] <JEEB> or at least ffmpeg now seems to have VDPAU hwaccel support
[11:55] <xagaba> with an actual ffplay version it's vdpau supported ?
[11:56] <JEEB> not that I can see
[11:56] <JEEB> I can see support added in ffmpeg
[11:56] <JEEB> no mention of ffplay
[11:57] <xagaba> ok thanks for clarifications JEEB ;-)
[11:57] <JEEB> np
[11:57] <JEEB> if you want playback btw, you might want to try out the mpv-build repository so you can build your own up-to-date mpv with newer components :)
[11:58] <JEEB> https://github.com/mpv-player/mpv-build
[11:58] <kolizer> Picture with a web cam behind the video screen http://pastebin.com/SRUqapCP
[11:58] <kolizer> how to fix?
[12:39] <fridus> Hi
[12:39] <fridus> I've problem with build on mac os x
[12:40] <fridus> Undefined symbols for architecture x86_64:
[12:40] <fridus>   "_ff_h263p_decoder", referenced from:
[12:40] <fridus>       _avcodec_register_all in allcodecs.o
[12:40] <fridus> could you help me ? :S
[14:15] <fridus> Hi
[14:16] <Voicu> hello, how do I use a filter programmatically?
[14:27] <fridus> i don't know
[14:28] <fridus> I've a question too
[14:44] <klaxa> fridus: just state your problem as precise as possible
[15:04] <Voicu> maybe it's not translatable into human language
[15:05] <Voicu> like that feeling you get when you talk about something deep and it seems like you're close to understanding something great but you can't just express it
[15:23] <fridus> sorry
[15:23] <fridus> I try to compile ffmpeg on mac os x
[15:24] <fridus> i would like make a shared lib ( .so)
[15:24] <fridus> But when it build, I see this error:
[15:24] <fridus> Undefined symbols for architecture x86_64
[15:25] <fridus> "_ff_h263p_decoder", referenced from:
[15:25] <fridus>       _avcodec_register_all in allcodecs.o
[15:25] <fridus>   "_ff_h264_set_erpic", referenced from:
[15:25] <fridus>       _ff_h264_decode_slice_header in h264_slice.o
[15:26] <fridus>   "_ff_mpegvideo_decoder", referenced from:
[15:26] <fridus>       _avcodec_register_all in allcodecs.o
[15:26] <Voicu> lol
[15:27] <Voicu> fridus, don't paste in here
[15:27] <fridus> where ?
[15:27] <Voicu> fridus, this is true for all support channels - you use a pastebin like pastebin.com
[15:27] <Voicu> so you don't clutter the chat with random code
[15:28] <fridus> oh ..
[15:29] <fridus> No issues on github ?
[15:29] <Voicu> fridus, hm?
[15:30] <fridus> I don't know where and how send my problem/bug to the support
[15:32] <c_14> https://ffmpeg.org/bugreports.html
[15:32] <c_14> But first, have you tried: https://trac.ffmpeg.org/wiki/CompilationGuide/MacOSX
[15:35] <fridus> thanks
[17:13] <blz> Hello, I have a collection of frames taken from a webcam (png images) that I would like to store as a video file.  Can such a thing be achieved with ffmpeg?
[17:13] <c_14> https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images
[17:18] <blz> c_14 that seems promising indeed! Thanks!
[18:41] <Phlarp> I have a question: Why does the apt-get package for ffmpeg install V 0.8.10?
[18:44] <c_14> The ffmpeg that is installed under debian and debian-derivatives is actually libav, and usually a rather outdated version thereof.
[18:45] <reventlov> Hello.
[18:47] <c_14> Hi, if you have a question just ask and if someone can help you, they will.
[18:49] <reventlov> I'm using ffserver on archlinux. When a client disconnect from ffserver, it segfaults.
[18:49] <reventlov> Version: http://sprunge.us/AdPF
[18:49] <reventlov> Is this a bug known ?
[18:50] <c_14> Do you have the ffserver output?
[18:51] <reventlov> Fri May  9 18:50:56 2014 127.0.0.1 - - [POST] "/rtsp.ffm HTTP/1.1" 200 1138688
[18:51] <reventlov> zsh: segmentation fault (core dumped)  ffserver -f /etc/ffserver.conf
[18:51] <reventlov> using : ffmpeg -i *.mp4 -override_ffserver -vcodec mpeg2video -b:v 3000 http://127.0.0.1:8090/rtsp.ffm
[18:51] <reventlov> ffserver.conf: http://sprunge.us/WMRY
[18:51] <xreal> Is there something like re-quantizising for x264 ?
[18:52] <reventlov> it's not automatic, but I can reproduce it by opening/closing ffmpeg and/or one client
[18:52] <reventlov> (like i just did)
[18:53] <JEEB> xreal, re-quantization? please explain
[18:53] <reventlov> I have one strace, if you want
[18:54] <xreal> JEEB: In the past, it was possible to re-quantizize a 9 GB DVD-video to fit in a DVD-R with little quality loss.
[18:54] <c_14> reventlov: You might want to submit a bugreport: https://ffmpeg.org/bugreports.html
[18:54] <reventlov> c_14: ok.
[18:55] <JEEB> xreal, ok -- so either just straightforward re-encoding or abusing the fact that MPEG-2 and DVDs were structurally so simple
[18:55] <xreal> JEEB: http://en.wikipedia.org/wiki/DVD_Shrink
[18:56] <JEEB> yeah, I know that piece of software
[18:56] <JEEB> anyways, it's just re-encoding and (possibly) abusing the fact of how simple MPEG-2 was as a format + how limited DVD Video is
[18:57] <JEEB> depending on your needs and how well the original file you're trying to compress is already compressed, you may be able to get some kind of results from re-encoding something
[18:57] <JEEB> (as the case is always)
[18:57] <kolizer> i overlay webcam on video and when i make screencast webcam no work. what problem?
[18:57] <JEEB> also, x264 is just an encoder, H.264 is the format
[18:58] <JEEB> (or AVC)
[18:58] <JEEB> so yeah, one can use the CRF rate control and the usual ways of encoding with libx264 to re-encode something
[18:58] <JEEB> I will have to say, though, that in many cases stuff encoded in H.264 already is quite compressed. Unless your source is a blu-ray or something.
[18:59] <xreal> JEEB: But re-quantizition (I think, that was the term used) was very, very quick
[19:00] <JEEB> I have no idea what that marketing term actually technically means
[19:00] <kolizer> Somebody help me?
[19:00] <JEEB> also as I said already, depending on what exactly that feature did
[19:00] <JEEB> it might have abused features of the MPEG-2 Video format, or the fact of how simple/limited DVD Video has to be
[19:01] <JEEB> also libx264 can be as fast or slow as you want, but the efficiency will of course vary
[19:02] <kolizer> i overlay webcam on video and when i make screencast webcam no work. what problem?
[19:04] <rafael2k> people, any knows if there are any free software MMT (MPEG 23008-1) out there?
[19:05] <JEEB> I tried to read through the spec and I didn't understand what exactly it was trying to be :P
[19:05] <JEEB> it's just some random crap on top of either MP4 or MPEG-TS?
[19:05] <rafael2k> MPEG-TS substitute
[19:05] <rafael2k> no
[19:05] <JEEB> doesn't seem to be a substitute
[19:05] <rafael2k> it's the evolution of MPEG-TS
[19:05] <JEEB> at least looking at the spec
[19:05] <rafael2k> it's much easier than MPEG2-TS
[19:06] <JEEB> have you read the spec?
[19:06] <JEEB> it's short as hell
[19:06] <rafael2k> don't carry that craps of legacy ATM stuff
[19:06] <JEEB> it doesn't specify a new format
[19:06] <rafael2k> I have the 2nd working draft
[19:06] <JEEB> I think I have the DIS or so
[19:07] <Phlarp> So, I have compiled / installed the 2.2.2 build and the commands I'm trying to use work when executed on the command prompt, but fail when called by shell_exec(). error log says sh: 1: ffmpeg: not found. Anyone know how to make this work?
[19:08] <c_14> ffmpeg isn't in your path, either use the absolute path to the binary or put it in your path
[19:08] <Phlarp> how do I put it in my path?
[19:10] <klaxa> export PATH=$PATH:/path/to/dir/containing/ffmpeg
[19:10] <klaxa> iirc
[19:11] <c_14> That'll only work for the current shell though.
[19:11] <klaxa> so if it is in /home/user/build/ffmpeg/ffmpeg add /home/user/build/ffmpeg to your PATH
[19:11] <klaxa> yeah put it in your .profile or .bashrc or whatever
[19:11] <klaxa> or copy/link/symlink ffmpeg to /usr/local/bin/ or see if make install installs it in the system
[19:12] <Phlarp> I need to make it executable by apache.
[19:12] <Phlarp> so I need to copy/symlink ffmpeg to apaches? /usr/local/bin?
[19:13] <reventlov> Reading symbols from ffserver...(no debugging symbols found)...done.
[19:13] <reventlov> is that a problem for a bugreport ?
[19:13] <klaxa> Phlarp: did you try running "make install" or "sudo make install" ?
[19:13] <reventlov> (there is no ffserver debug bin)
[19:13] <kolizer> i overlay webcam on video and when i make screencast webcam no work. what problem?
[19:13] <klaxa> that should install it in /usr/local/ or whatever directory you specified with --prefix= during ./configure
[19:14] <Phlarp> Yes, I have it made and installed already; it works fine when invoked from a commandline but not when triggered by a webpage script
[19:14] <c_14> reventlov: You need to compile ffmpeg/server with debug symbols enabled/without strip.
[19:14] <reventlov> ok, let's go.
[19:14] <reventlov> without --disable-debug
[19:15] <reventlov> nothing related to "strip" in the options I pass.
[19:15] <reventlov> --disable-stripping so.
[19:16] <reventlov> that's it ?
[19:16] <klaxa> Phlarp: then you need to either specify the full path in the script (i.e. /usr/local/bin/ffmpeg) or add /usr/local/bin to that... "shell"'s path
[19:16] <klaxa> using the full path might be easier
[19:16] <JEEB> rafael2k, I went through the spec once again and I see MPUs ("An MPU shall be encapsulated as a single ISOBMFF file") and something called MMT payload (?)
[19:17] <c_14> reventlov: think so
[19:17] <reventlov> Do i need   --enable-memalign-hack   emulate memalign, interferes with memory debuggers ?
[19:17] <c_14> don't think so...
[19:18] <JEEB> and actually.. looking forward in this, an awful lot of the stuff is just putting stuff into ISOBMFF
[19:18] <JEEB> I don't see a "replacement for MPEG-TS" here at all
[19:19] <rafael2k> no?
[19:19] <rafael2k> how?
[19:20] <rafael2k> there is packet, MPUs, system clock, FEC...
[19:20] <JEEB> yeah. I can see those packets
[19:21] <JEEB> this seems more like a (network) protocol than what MPEG-2 Systems is
[19:21] <rafael2k> the packet can have arbitrary size, not hardcodec 188bytes, what I didn't understand is the use of HTML5 in the transport standard...
[19:21] <JEEB> yeah, this thing seems to be quite overcomplicated :P
[19:22] <JEEB> (also whatever you sent me sure doesn't seem to have gone anywhere)
[19:22] <rafael2k> no no, indeed, all the clock stuff is much easier
[19:22] <rafael2k> it uses NTP clock syntan
[19:22] <rafael2k> also the fragmentation and buffer model seems easier
[19:22] <rafael2k> (I just passed the eyes in the standard)
[19:24] <rafael2k> but they mixed the presentation definition in it, seems not very correct
[19:25] <JEEB> yeah, it's a rather messy spec :P
[19:25] <rafael2k> true
[19:25] <JEEB> first they give you some crap that is supposed to go into an ISOBMFF file
[19:25] <rafael2k> I'll try to get the final draft to check if things got better
[19:25] <JEEB> then they give you something more
[19:25] <JEEB> and then there's the MMT Protocol
[19:25] <rafael2k> the ISOBMFF AU goes inside the MPUs, as I could understand
[19:27] <JEEB> but yeah, the spec is a mess and it truly doesn't make me feel like I want to touch it at all
[19:28] <rafael2k> eheheheh
[19:28] <rafael2k> I'll try to play a little bit
[19:28] <rafael2k> <- now working w/ hybrid broadcast
[19:29] <JEEB> if you can explain me later WTF this thing is supposed to actually be, I'd be rather thankful. Because so far it just seems like a mess
[19:30] <JEEB> it's not simply a container, it's some kind of a hackjob to also communicate between a client and a server or whatever
[19:33] <JEEB> ahaha
[19:33] <JEEB> jesus christ
[19:33] <JEEB> http://mpeg.chiariglione.org/standards/mpeg-h/mpeg-media-transport/use-cases-mpeg-media-transport-mmt
[19:33] <JEEB> I checked out this document
[19:33] <JEEB> first two Use Cases: Ultra-HD Content, 3D Video Content
[19:34] <JEEB> THOSE ARE NOT CONTAINER SPECIFIC THINGS FOR FUCK'S SAKE
[19:34] <JEEB> > Interactive 3D content
[19:34] <JEEB> ok, this makes sense, but... this smells like the most unused parts of MPEG-4
[19:35] <JEEB> and the most convoluted etc as well
[19:36] <JEEB> and a lot of this crap is something that IMHO is application-side stuff
[19:36] <JEEB> not _container_ side stuff
[19:36] <JEEB> that said, it already defines a goddamn protocol
[19:36] <rafael2k> JEEB: I'm discussing here in the lab, it uses ISOBMFF
[19:36] <JEEB> why does this remind me of the crappiest parts of MPEG-4?
[19:36] <JEEB> yes, that's what I gathered so far
[19:36] <JEEB> crap on top of ISOBMFF
[19:36] <rafael2k> so, lots of redundancy in MPEG-2 (lots of tables and so on) were removed
[19:37] <rafael2k> btw, I don't like MPEG-4 file format also..
[19:37] <reventlov> Anyone on archlinux could compile ffmpeg with the debug flags for x86_64 ? Ty.
[19:37] <JEEB> well, at least the MPEG-4 file format was a container
[19:37] <JEEB> and not some...
[19:37] <rafael2k> the hierarquical FEC is nice
[19:37] <JEEB> I don't even know what the flying fuck this is so far :D
[19:37] <reventlov> c_14: i'm using archlinux, and it seems there is a bug related to gcc 4.9. Is this a problem for my bugreport ?
[19:38] <reventlov> Oh, it's fixed.
[19:38] <reventlov> Nevermind.
[19:39] <rafael2k> for broadcast multiple layers for protection is nice
[19:39] <JEEB> but yeah, I probably wouldn't call this a new container :P
[19:39] <rafael2k> for example, when using SVC, and can protect the base video stream with a more robust FEC, and the upscale stream in a less robust FEC level
[19:40] <JEEB> > someone actually using SVC
[19:40] <JEEB> wow.jpg
[19:40] <rafael2k> :P
[19:40] <rafael2k> JEEB, I'm only doing research, not real use yet...
[19:40] <JEEB> well, yeah
[19:40] <rafael2k> the idea is to use this in the next generation of hybrid broadcast systems
[19:41] <JEEB> the whole MMT thing sounds like something reasearchers came up with
[19:41] <rafael2k> (I'm doing this for Brazil)
[19:41] <JEEB> with all due respect to researchers
[19:41] <JEEB> just like certain very unused things in MPEG-4
[19:41] <rafael2k> true
[19:41] <rafael2k> like BIFS
[19:41] <JEEB> oh yes
[19:41] <JEEB> yes
[19:41] <rafael2k> and many other parts of MPEG-4 that are _very_ complicated
[19:41] <JEEB> "let's not have a thing for chapters, instead people can implement them in BIFS!"
[19:42] <rafael2k> btw, there is no Brazilian in MPEG board...
[19:42] <rafael2k> :P
[19:42] <JEEB> and then no-one implemented them in BIFS because Nero had one hack, and others just derped with the MOV way
[19:42] <JEEB> (and the MOV CHAP atom is now actually noted as something you shouldn't use)
[19:43] <rafael2k> the new standards from mpeg I'm interested in understanding better is the xHE-AAC one, the HEVC and the 3-D audio one
[19:43] <JEEB> HEVC is nice
[19:43] <JEEB> simplified AVC with features for extra compression
[19:44] <JEEB> no PAFF/MBAFF \o/
[19:44] <rafael2k> good!
[19:44] <JEEB> the 3-D Audio one is not around at all yet
[19:44] <rafael2k> how can you do interlaced content?
[19:44] <JEEB> rafael2k, normal coding modes and just in the parameter sets you note that this is a field
[19:44] <rafael2k> good
[19:45] <rafael2k> 3-D audio is nice, I'm extending the Ginga middleware to add 3-D audio, not that complicated
[19:45] <JEEB> last I checked the audio part of MPEG-H wasn't yet done
[19:45] <rafael2k> that is the good part
[19:46] <rafael2k> I'm not doing my work based in MPEG-G
[19:46] <rafael2k> MPEG-H part 3
[19:46] <rafael2k> ; )
[19:46] <JEEB> heh
[19:46] <rafael2k> KISS aproach
[19:46] <JEEB> but yeah, so far my opinions on MPEG-H vary from "this is pretty good" (Part 2) to WTF (Part 1)
[19:46] <JEEB> and other parts aren't done yet
[19:46] <JEEB> :D
[19:46] <rafael2k> good to know part 2 is good
[19:47] <rafael2k> and that SVC and MVC is compatible with HEVC also?
[19:47] <JEEB> well, good on the ISO/IEC and ITU-T level
[19:47] <JEEB> scalable extensions are probably gonna get in this year or so
[19:47] <JEEB> range extensions also
[19:47] <JEEB> range extensions will have actually useful stuff
[19:47] <JEEB> such as 4:2:2/4:4:4 and >10bit
[19:47] <JEEB> scalable extensions has some random shit corps came up with
[19:48] <rafael2k> I'm very interested in SVC
[19:48] <JEEB> it looks cool on paper
[19:48] <JEEB> but in the end it doesn't get any usage if at all
[19:48] <JEEB> I know like a couple of things that use SVC and that's it
[19:48] <rafael2k> it is important for backward compatibility, at least in theory, with millions are already sold TV sets...
[19:49] <JEEB> and in reality you just switch streams :P
[19:49] <rafael2k> but this is the web, the broadcast enviroment is much more restrictive
[19:49] <JEEB> also yeah, seems like 3-D Audio has only started http://itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG-H
[19:50] <rafael2k> true, this is why is important to come up fast with a good 3D audio standard before MPEG
[19:50] <rafael2k> mainly fraunhofer is doing it...
[19:51] <JEEB> also regarding HEVC, http://www.f265.org/f265/static/txt/h265_companion.html
[19:51] <JEEB> you can smirk at the rant :P
[19:53] <rafael2k> tks!
[19:53] <rafael2k> ; )))
[19:54] <JEEB> but yeah, you'll get more scalable shit into HEVC this year
[19:55] <rafael2k> good
[19:55] <rafael2k> it's not shit!
[19:55] <rafael2k> :P
[19:56] <JEEB> but yeah, all of the first three amendments are now past DIS, only FDIS left
[19:59] <reventlov> ffmpeg version 2.2.2 Copyright (c) 2000-2014 the FFmpeg developers
[19:59] <reventlov> is this the latest developpment version ?
[20:00] <reventlov> Because i made all my logs with that :')
[20:00] <JEEB> no
[20:00] <JEEB> that's the latest release
[20:00] <reventlov> fuck.
[20:00] <JEEB> latest development version means current git master HEAD
[20:00] <reventlov> so, i can just throw all my logs, i guess.
[20:01] <reventlov> and i must recompile ffmpeg.
[20:01] <reventlov> -_-
[20:01] <iive> it is 4-5 days old release
[20:01] <JEEB> based on an older branch :)
[20:01] <JEEB> how new/old a release is, is kind of deceptive
[20:02] <reventlov> so, do i *have* to recompile using git or not ?
[20:02] <JEEB> if you want to check a checkbox that says "I've tested with the latest development version" then yes, otherwise just note that you've only tested with the latest 2.2 branch release
[20:04] <reventlov> 2.2.2 is not listed on trac, btw
[20:04] <JEEB> probably no-one just input it :)
[20:04] <iive> cut from master on 2013.03.01 yeh, old branch.
[20:05] <JEEB> like the topic of this channel, which still has 2.2.1 as the latest release ;)
[20:05] <iive> reventlov: btw, gcc 4.9 is known to miscompile ffmpeg
[20:06] <iive> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902
[20:06] <JEEB> that of course only matters if you built the ffmpeg with 4.9.0 GCC
[20:06] <reventlov> iive: fixed with the last gcc package here
[20:06] <reventlov> https://bugs.archlinux.org/task/40256?string=ffmpeg&project=1&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
[20:07] <JEEB> I guess they did the same as I did with my test mingw-w64 toolchain, just took current 4.9 branch and stuck those two commits on top
[20:10] <reventlov> « I have files to attach to this ticket »
[20:10] <reventlov> where do i put these files ?
[20:13] <reventlov> https://trac.ffmpeg.org/ticket/3630
[20:14] <reventlov> ok, done.
[20:15] <JEEB> nice. also just a note for the future: generally the importance of tickets is only set by developers, so in the future you could just leave it to "normal" or whatever it was :)
[20:15] <reventlov> ok, sorry.
[20:43] <rafael2k> I don't know if this is of interest, but I'll be maintaining a debian 8/ubuntu 14.04 repo of ffmpeg with 'ffmpeg' library suffix here: www.telemidia.puc-rio.br/~rafaeldiniz/ginga4linux/debian/amd64/
[20:44] <rafael2k> I really don't understand why debian and ubuntu keeps using libav...
[20:46] <JEEB> when libav forked off it kind of seemed promising, and the debian/ubuntu ffmpeg maintainer is a libav developer
[20:47] <rafael2k> wtf
[20:47] <rafael2k> any hope things will going to change?
[20:47] <JEEB> basically, both ffmpeg and libav are better than ffmpeg-old
[20:48] <JEEB> I'm not seeing it changing in general
[20:48] <rafael2k> and how about make ffmpeg and libav not conflit in terms of library names?
[20:49] <rafael2k> so then both could make it's way in debian/ubuntu repos
[20:50] <JEEB> probably not going to happen either
[20:50] <rafael2k> :/
[20:50] <rafael2k> So I'll keep shouting to keep ffmpeg instead of libav
[20:50] <rafael2k> :P
[20:53] <rafael2k> btw, library suffix solved my issue with the software I'm developing, but I need to maintain ffmpeg, but not problem.. next thing is to make static linking work here...
[23:25] <xreal> JEEB: I figured out about DVDshrink. It doesn't need to do calculation of the motion vectors and other stuff. So transcoding is much faster.
[23:25] <xreal> I think, this won't work for x264, does it?
[23:25] <JEEB> you basically have to poke the encoder's internals inside out
[23:25] <JEEB> for that
[23:26] <JEEB> also it's not always something that works
[23:26] <xreal> JEEB: I think, some video cutting applications can do this.
[23:26] <xreal> JEEB: Smart Transcoding
[23:26] <JEEB> that's another thing
[23:26] <JEEB> that usually means that they let you cut on specific pictures even if not a random access point
[23:26] <JEEB> and re-encode what's needed
[23:27] <JEEB> otherwise trying to be "smart" about re-encoding can just end up kicking you in the arse
[23:27] <JEEB> I'm not sure it always is worth it
[23:27] <JEEB> or well, I'm not sure if it really is worth it ever :s (esp. with the speed of fast encoding in general nowadays, with f.ex. libx264)
[23:28] <xreal> JEEB: So I think. there isn't a fast way to resize 1920 to 1080 :)
[23:30] <JEEB> xreal, if you're not being bandwidth-limited between VRAM<->RAM transfer I see you being able to resize pictures rather well with OpenGL/Direct3D/etc
[23:31] <xreal> JEEB: Oh, I want to create a 1080 file actually, not in realtime playback.
[23:31] <JEEB> xreal, you want to resize something, no?
[23:31] <xreal> JEEB: Yes, but can I do it with my GPU?
[23:32] <reventlov> What options would you use to stream any mp4 found online using ffserver ?
[23:32] <reventlov> I use  ffmpeg -i foobar.mp4 -override_ffserver -vcodec mpeg2video -b:v 3000 http://127.0.0.1:8090/rtsp.ffm
[23:32] <JEEB> xreal, why not? picture stuff is actually what that hardware was meant for after all
[23:32] <reventlov> and it's ugly.
[23:32] <xreal> JEEB: Does ffmpeg support this?
[23:32] <JEEB> of course VRAM<->RAM transfer can be a bottleneck depending on how you implement the stuff
[23:32] <JEEB> xreal, of course not
[23:32] Action: xreal is confused
[23:32] <JEEB> write your own stuff \o/
[23:32] <xreal> :D
[00:00] --- Sat May 10 2014


More information about the Ffmpeg-devel-irc mailing list