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

burek burek021 at gmail.com
Wed Sep 24 02:05:01 CEST 2014


[00:30] <jverce> Hi there. I want to use FFmpeg from Java. What is the most used binding for the framework? What I need to do is mainly redirect video stream from one source to another, store the input video stream into chunks, and also take thumbnails in a regular pace.
[00:49] <Rathann> jverce: you can use JNI to call FFmpeg libs directly
[00:52] <foobarz> what cpu type or cpu feature (instructions, AVX etc) are most important for fast 2160p HEVC playing?
[00:52] <Rathann> jverce: looks like the few ffmpeg-java projects which were there are mostly dead
[00:52] <Hello71> vaapi.
[00:53] <BtbN> vaapi for h265? nope.
[00:53] <BtbN> CORES are most important
[00:54] <BtbN> throw 8 3GHz physical cores at it, and it should work
[00:54] <BtbN> If the cores are not Pentium 4 or something like that.
[00:56] <foobarz> So that means Core i5 cpus are not really adaquate for 2160p HEVC? Wow. That is a lot of mainstream CPUs.
[00:57] <foobarz> I just am trying to figure out these requirements for my next PC build.
[01:01] <Suchiman> well i could test how 2160p playback performs on a 4670K but i do not have 2160p HEVC Content lying around xD
[01:02] <foobarz> there is a downloadable sample of that 2160p HEVC on the web
[01:02] <foobarz> it shows cows in a field and stuff
[01:03] <llogan> someone offers to test and you say "it's on the web".
[01:04] <foobarz> the time is nearly come for a hw website to do a benchmarking article on how 2160p HEVC plays on various PC configurations
[01:04] <theholyduck> llogan, itsn ot like we have all these links lying around :P
[01:04] <theholyduck> foobarz, but, there was a long period of h264, where the large majority of desktop cpus people had
[01:04] <theholyduck> wouldnt be able to play it back
[01:05] <theholyduck> but, decoders got faster, and cpus got faster.
[01:05] <theholyduck> and, now its not that much of an issue in most cases
[01:06] <foobarz> samples are here... http://www.elecard.com/en/download/videos.html
[01:06] <theholyduck> foobarz, also, thats quite a bit of looking forward to, a video format and standard thats still quite a bits off?
[01:06] <foobarz> i downloaded the 4K of cows
[01:08] <theholyduck> like, i fully expect to be on an all new build by the time i start running into HEVC in the wild
[01:08] <foobarz> 2160p HEVC is going to take over in just a few more months
[01:08] <theholyduck> foobarz, why?
[01:08] <BtbN> The next nvidia GPUs have hardware decoding for up to 8K anyway, so that problem is gone in a year or so.
[01:08] <BtbN> The more interesting thing is: They also have hardware _en_coding support for it.
[01:09] <theholyduck> BtbN, most hardware encoders are pretty poop though
[01:09] <theholyduck> see, all the hardware h264 encoders ever
[01:09] <theholyduck> foobarz, put it like this, from the time i saw my first h264 file in the wild
[01:09] <BtbN> Of course they are not as good as x264, but they are more than ok.
[01:09] <theholyduck> to, it being in common usage online.
[01:10] <theholyduck> foobarz, was probably atleast 5 years
[01:10] <BtbN> the problem is, CPUs aren't getting faster anymore at the same rate as 5 years ago
[01:10] <theholyduck> thats basicly the time it took, for most people to have the cpu power to deal with it.
[01:10] <theholyduck> and, the people creating videos having confidence in the encoding tools
[01:10] <theholyduck> etc.etc
[01:11] <BtbN> h265 will not be common before 16 or more physical cores have become a common thing
[01:11] <theholyduck> and even, then, it was quite a while, before like, the scene, started using it
[01:12] <BtbN> The thing is, more storage and bandwidth is cheaper than getting more encoding power. So h264 at a higher bitrate it is.
[01:12] <theholyduck> BtbN, also, encode time.
[01:12] <theholyduck> i havent played much with HEVC yet
[01:12] <theholyduck> but, vp9 encode times are just atrocious
[01:12] <BtbN> I can get 1 fps out of my i5-2500k for encoding 1080p
[01:12] <theholyduck> sure, you get better video quality, but it takes you like 10 times longer to encode the same file with vp9 to h264
[01:13] <theholyduck> er, vs h264
[01:13] <theholyduck> and thats x264 --placebo
[01:13] <theholyduck> i havent kept up on x265 development, but last i heard, it was just the concept encoder, with some slight tweaks
[01:14] <theholyduck> no relation to x264
[01:14] <foobarz> i did notice that it took my cpu 16 threads to play the cows smooth
[01:14] <BtbN> It aims to get for h265 what x264 is for h264
[01:14] <theholyduck> BtbN, but, they started by just copying the concecpt encoder source base
[01:14] <BtbN> Their goal for encoding is: 1080p, 30fps, in realtime on a 16 core xeon.
[01:14] <theholyduck> and starting from that
[01:14] <theholyduck> x264 started from scratch with no badly done structure to start with
[01:15] <theholyduck> and it still, took forever to become decent
[01:15] <theholyduck> what was it, like, 2-3 years of x264 development before it stopped being terrible
[01:15] <theholyduck> another 3-4 before it was commonly used
[01:15] <theholyduck> foobarz, theres a reason all the initial blurays were mpeg2, and then vc-1
[01:16] <theholyduck> cause even though h264 had been a spec for quite a while at that point
[01:16] <theholyduck> people didnt have decent encoders to create content for it
[01:16] <JodaZ_> mpeg2 ?_?
[01:16] <JodaZ_> not even mpeg4?
[01:16] <theholyduck> JodaZ_, narp :P
[01:16] <BtbN> I'm somewhat into video streaming, and the if you do stream 1080p60, you loose like 10-30% of your viewership, because their PCs are too weak to decode it in realtime.
[01:16] <Suchiman> foobarz: configuration is i5 4670K overclocked to 4,4GHz (Default clock is 3,4, Turbo up to 3,8), 1x8GB 1600MHz RAM, AMD Radeon R9 270X, W8.1 Pro x64. With a native 1920x1080 Monitor attached through HDMI, ffplay consumes between 70% and 90% CPU. Tested on the 4K material: Elecard 4K video about Tomsk, part 3
[01:17] <JodaZ_> dvd's are mpeg4 tho aint they?
[01:17] <kepstin-laptop> JodaZ_: mpeg4 isn't in the bluray spec. dvd is mpeg2.
[01:17] <BtbN> So it will take decades for h265 to become even somewhat interesting.
[01:17] <theholyduck> JodaZ_, narp
[01:17] <theholyduck> JodaZ_, dvds are mpeg2
[01:17] <JodaZ_> °.°
[01:17] <theholyduck> mpeg4 was mostly a disaster, outside of the mpeg4-asp
[01:17] <JodaZ_> divx not good?
[01:17] <theholyduck> JodaZ_, divx/xvid is mpeg4-asp
[01:18] <theholyduck> kepstin-laptop, well to be fair, in theory, h264 is mpeg4-avc
[01:18] <theholyduck> so, in a sense, mpeg4 is on bds
[01:19] <theholyduck> but, most people dont refer to h264 as mpeg4, so the point is sort of moot
[01:19] <kepstin-laptop> yeah, I suppose. assume I said mpeg4-asp when I said mpeg4 :)
[01:19] <theholyduck> kepstin-laptop, mopst people do mean thatr
[01:19] <theholyduck> i just find its better to be absolutely clear about those things
[01:19] <theholyduck> but yeah, initial bds were mpeg2, and then vc-1
[01:19] <theholyduck> cause, h264 encoders were still shit
[01:20] <theholyduck> and even when they started using h264 on bds, the encoders were still pretty subpar
[01:20] <theholyduck> foobarz, so yeah, give it a while for people to write, decent encoders that can actually be used on a day to day basis, and actually utilize a decent chunk of the formats capabilities
[01:21] <theholyduck> and the majority of people having the ability to play back the content without having to worry about a thing
[01:21] <Suchiman> foobarz: VLC nightly didn't Play the video material, it played about 0,5 seconds, then it stopped and only consumed CPU
[01:21] <theholyduck> h264s main benefit was that it was supported, by flash
[01:21] <theholyduck> so, absoluytely everyone had a h264 decoder that just worked
[01:21] <theholyduck> well, 1 of its main benefits
[01:21] <theholyduck> with no need to install anything, or do much of anything.
[01:22] <foobarz> Suchiman: i recommend you test with freshly compiled MPlayer and ffmpeg (internal) from snaphots. Somehow mplayer is a lot faster for me.
[01:22] <Suchiman> foobarz: well, it was the ffplay from the recent zeranoe build
[01:23] <Suchiman> foobarz: i will test mplayer
[01:25] <Suchiman> foobarz: MPlayer only consumed 30~35% CPU (mhh wondering wether that means it's only consuming one core), it is noticeable lagging and spaming the console with:
[01:25] <Suchiman> No pts value from demuxer to use for frame!
[01:25] <Suchiman> pts after filters MISSING
[01:27] <foobarz> Suchiman: mplayer command for me was: mplayer -lavdopts threads=16
[01:28] <Suchiman> foobarz: i only haz 4 threads and cores :P
[01:28] <foobarz> Suchiman: mplayer -lavdopts threads=16 -really-quiet
[01:29] <foobarz> because mplayer seems to work so well, i got the idea usage of HEVC is coming in the next few months already... with the new GTX 900 cards hw encoding is supposed to be coming too
[01:30] <foobarz> seems like all the pieces to use HEVC are showing up working
[01:32] <Suchiman> foobarz: much better, mplayer -lavdopts threads=4 -really-quiet 140803_4k_hm130_4s_sao_dbf_qp27.265 <-- 40~50% at slow Motion and up to 65% at quick Motion (cows) (4 cores / 4 threads, all together clocked at 4,4)
[01:33] <foobarz> you could try 8 threads. it seemed to like threads for me
[01:33] <Suchiman> foobarz: why should i try 8? well anyway lets see :P
[01:34] <foobarz> Suchiman: i also wonder how it works for you if you were not overclocked
[01:35] <Suchiman> foobarz: doesn't makes any difference (8), same usage and both very smooth
[01:35] <Suchiman> foobarz: 1GHz Bonus - more Cache misses in the worst case
[01:36] <foobarz> Suchiman: that video looks awesome quality... this is why i want to see this encoder working... it makes smaller files too
[01:36] <Suchiman> foobarz: yeah
[01:36] <Suchiman> foobarz: but the Encoder Needs to get faster and more efficient :o
[01:36] <Suchiman> veryslow h264 is almost as good and fast as normal h265
[01:37] <Suchiman> making h265 slower is almost like choosing placebo
[01:38] <foobarz> Suchiman: i use mplayer as my regular player... it is the best for me
[01:39] <Suchiman> foobarz: but it's way to cmdline and stuf
[01:40] <foobarz> i'm okay with cmd line... i make text file playlists and have made right-click start tools on my file browser
[01:40] <Suchiman> using mainly Windows media player enhanced with http://shark007.net/ (less intrusive than k-lite and almost invisible, also makes preview for all the files in explorer without problems), for the rest vlc and for experiments ffplay
[01:43] <Suchiman> foobarz: oh well, windows media player also plays this file ;) using about 10% more CPU than mplayer
[02:05] <foobarz> Suchiman: thx for testing that. interesting to know a quad core i5 can play it smooth :)
[02:06] <Suchiman> i wonder how much difference hyper threading would make
[02:08] <foobarz> Suchiman: another factor for all video playback smoothness is correct amount of disk caching if the HDD is slow. i'd have to try different cache sizes to see if it matters but i barely got smooth play near 100% of my cpu usage
[02:08] <Suchiman> foobarz: heh, i guess my 840 SSD will deliver enough Speed for dat
[08:56] <K4T> is here somebody who ave some experience with nginx rtmp module + ffmpeg?
[10:37] <fling> http://lurkmore.so/images/6/69/Blacklines.JPG
[10:42] <fling> how to fix? ^
[10:51] <Sokolio> hmm, perhaps providing the commandline input would be more helpful?
[12:04] <Diogo>  debug: [mpegts @ 0x7f1934070360] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead.
[12:04] <Diogo> do you know if this warning already correct in branch master?
[12:29] <wintershade> hey guys! me again :P
[12:29] <wintershade> question. how come the hxq filters don't work anymore? have they been replaced by something?
[12:31] <ubitux> hxq?
[12:32] <wintershade> ubitux: this --> https://www.ffmpeg.org/ffmpeg-filters.html#hqx
[12:32] <ubitux> hqx, right
[12:32] <ubitux> what do you mean that dont work anymore?
[12:33] <wintershade> oops. typo on my end.
[12:33] <wintershade> ffmpeg gives me this error: "No such filter: 'hqx'"
[12:33] <ubitux> what version?
[12:33] <wintershade> 2.2.7
[12:33] <ubitux> was it present in this release?
[12:34] <wintershade> no idea. I know earlier releases had it...
[12:34] <ubitux> they were added in 2.3
[12:34] <wintershade> that's why I'm asking what happened to it.
[12:34] <ubitux> there weren't in earlier releases
[12:34] <wintershade> uh... 2.3? are you sure? I clearly remember it working a few months ago.
[12:35] <ubitux> we are in 2.4 currently
[12:35] <ubitux> they were added after 2.2, and were in the 2.3 release
[12:35] <ubitux> check the Changelog
[12:36] <wintershade> I see. for some reason, I had 2.3 installed on my system previously, then it... updated(?) to 2.2.7 then.
[12:36] <wintershade> note - I'm on Gentoo. Has there been some regression that made Gentoo mask the 2.3/2.4 version?
[12:36] <ubitux> no idea what broken system you use
[12:36] <ubitux> not sure
[12:36] <wintershade> Gentoo is not broken...
[12:36] <wintershade> but let's not get into religious discussions.
[12:37] <ubitux> if your system is upgrading packages from 2.3 to 2.2.7 then it's broken, or you're doing something wrong
[12:37] <ubitux> anyway, ask your distro
[12:38] <wintershade> hmm, okay. anyway, ffmpeg 2.3.3 is marked as unstable on amd64 here, and there is no sign of ffmpeg 2.4 in the portage tree.
[12:38] <wintershade> ...probably due to the fact that it's been released yesterday :D
[12:38] <wintershade> alrighty, I'll hang on for an update.
[12:39] <ubitux> it wasn't release yesterday
[12:39] <ubitux> only the revision
[12:39] <wintershade> right. I see that now, just browsing the main website. when was 2.4 released?
[12:40] <ubitux> not long ago
[12:40] <ubitux> about 10 days ago
[12:40] <wintershade> ugh. I'm looking at the Gentoo's "roadmap" for the ebuild... 2.2.7 is marked as unstable, 2.3.3 is hardmasked, and 2.4 doesn't exist yet.
[12:40] <wintershade> I'll ask the guys there.
[12:43] <wintershade> another question. any idea/recommendation for a good deblocking filter? I've found mp=uspp, but I'm not sure if it will do the trick properly...
[12:44] <wintershade> btw, ubitux I must say I really like your blog ;)
[12:45] <ubitux> thanks, but i'm not posting much on it :p
[12:45] <ubitux> maybe i will when i'm done with subtitles, but that's boring stuff
[12:46] <wintershade> ubitux: subtitles?
[12:46] <ubitux> no opinion on pp filters, -vf pp is native if you want, but uspp might provide better results
[12:46] <wintershade> also, I feel your pain about classifying music.
[12:46] <wintershade> yeah, although uspp is called ULTRA SLOW for a reason...
[12:47] <ubitux> mp={pp7,fspp} might be interesting
[12:47] <ubitux> ah, and -vf spp
[12:47] <ubitux> forgot i ported that one
[12:48] <wintershade> good on you about that one!
[12:48] <wintershade> does it work faster when ported?
[12:48] <ubitux> i doubt it really makes a difference
[12:49] <ubitux> it probably save the mp overhead, that's all
[12:49] <wintershade> as I thought.
[12:49] <ubitux> gtg
[12:49] <ubitux> bye
[12:49] <wintershade> cheerio~
[13:08] <pa> noob question: how to compile the sample programs shipped with ffmpeg sources?
[13:30] <pa> i tried with simply using Make, but it seems that the makefile does not properly configure PKG_CONFIG_PATH
[13:31] <c_14> export PKG_CONFIG_PATH=/path/to/wherever/lib:$PKG_CONFIG_PATH ?
[13:44] <pa> that did it, thanks! but now i get a weird compilation error: ffmpeg_sources/ffmpeg/libavutil/time.c:60: undefined reference to `clock_gettime
[13:50] <ubitux> pa: did you see the README in the doc/examples directory?
[14:01] <pa> yes
[14:03] <pa> i tried make examples, it doesnt work. i then tried to make in the examples directory, it kind of builds, but then it fails with that error
[14:05] <ubitux> what doesn't work?
[14:05] <ubitux> if you ran configure it should work
[14:06] <pa> ffmpeg built just fine
[14:06] <pa> but make examples fail
[14:06] <ubitux> how
[14:13] <anshul_mahe> pa pb!
[14:13] <anshul_mahe> pa !pb
[14:15] <anshul_mahe> I think you need to install ffmpeg and see if .pc are there in default PKG_CONFIG_PATH
[14:19] <ubitux> anshul_mahe: it's !pb <nickname>
[14:20] <anshul_mahe> thanks, for next time i will remember
[14:35] <pa> ok no, it works, it's that i make clean'ed before.
[14:36] <pa> (as per instructions)
[14:39] <Akagi201> How can I use ffmpeg to push rtmp stream to a rtmp server?
[14:41] <pa> anyhow, in the example transcoding.c, what output encoders are used?
[14:42] <pa> or how to choose them?
[14:51] <anshul_mahe> change the transcoding.c
[14:51] <anshul_mahe> there is enum inside
[14:54] <pa> ah great thanks
[14:57] <pa> so by simply calling transcoding somefile.mp4   somefile.mkv i get an x264 error: http://paste.ubuntu.com/8410635/
[14:59] <pa> maybe it's easier if i modify ffmpeg.c
[15:17] <pa> forgive my ignorance, but how does ffmpeg_parse_options initialize the context? it declares a private context object and returns an int..
[15:17] <pa> it doesnt even have dependency injection
[15:29] <pa> is there some page describing the design of ffmpeg?
[15:29] <Sokolio> nope
[15:29] <pa> i see
[15:29] <Sokolio> use the source, Luke
[15:29] <pa> i am trying
[15:30] <ubitux> pa: what design exactly?
[15:30] <ubitux> there is actually.
[15:30] <pa> still dont get how ffmpeg_parse_option communicate the parsing results to the rest of the program
[15:30] <Sokolio> ubitux: pelas elaborate on this
[15:30] <csepulvedab> hello guys.
[15:30] <Sokolio> There's doxy alright
[15:30] <csepulvedab> any one try to cut a video useing seek option?
[15:31] <ubitux> Sokolio: well, maybe http://ffmpeg.org/ffmpeg.html#Detailed-description and http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/ffmpeg.txt;hb=HEAD
[15:31] <ubitux> some stuff might have been renamed since i did that though
[15:31] <spaam> soo ffmpeg is using libav. hmmmm
[15:31] <ubitux> spaam: note the *
[15:31] <Sokolio> oh, right
[15:32] <Sokolio> I'm usually using libs
[15:32] <spaam> ubitux: nice asciiart :)
[15:32] <Sokolio> but yes, all the stuff can be queried, like AVOptions
[15:33] <Sokolio> is there a separate irc channel for ffmpeg libs?
[15:33] <ubitux> csepulvedab: http://trac.ffmpeg.org/wiki/Seeking%20with%20FFmpeg
[15:33] <ubitux> Sokolio: not really, you're supposed to ask here
[15:33] <csepulvedab> we use seek and the result video show twice the first frame
[15:33] <csepulvedab> for example:
[15:33] <csepulvedab> ffmpeg -y -i gop_10.mp4 -acodec aac -strict -2 -vcodec libx264 -ss 5.00500 -vframes 60 -level 31 -profile:v baseline 1.mp4
[15:34] <csepulvedab> the result video has 60 frames
[15:34] <Sokolio> alright, here it goes: is there a DVB subtitle encoder in ffmpeg which encodes bitmap subs (nit plain text)?
[15:34] <csepulvedab> but the first frame show frame 0 from second 5
[15:34] <csepulvedab> and second frame show too the frame 0 from second 5
[15:35] <csepulvedab> we know that because the original video has timestamp burned
[15:35] <csepulvedab> any one can reproduce this?
[15:35] <ubitux> Sokolio:  ffmpeg -v quiet -codecs|grep dvbsub says yes
[15:35] <Sokolio> I know
[15:36] <Sokolio> but it still doesn't render subs in the most common format, which is runlength encoded bitmaps
[15:36] <Sokolio> I was thinking about developing one but where to start
[15:37] <Sokolio> or maybe develop the existing one
[15:37] <Sokolio> there probably exists a #ffmpeg-devel channel
[15:37] <Sokolio> yup
[15:39] <csepulvedab> anyone? :) y try with different videos
[15:40] <csepulvedab> and always happen this to me.
[15:40] <Sokolio> and looking at the source, there is a possibility to render bitmaps, I wonder how to use it
[15:40] <Sokolio> csepulvedab perhaps this is a bug
[15:41] <csepulvedab> https://ffmpeg.org/pipermail/ffmpeg-user/2014-September/023590.html
[15:41] <csepulvedab> i want someone els can reproduce this before report it.
[15:48] <Sokolio> ok
[15:48] <Sokolio> I have 2.3.3 at hand
[16:12] <Sokolio> @csepulvedab, I confirm
[16:12] <Sokolio> With ffmpeg 2.3.3 I also got duplicate first frames
[16:22] <pa> why am i not able to find av_write_header with rgrep?
[17:16] <Phlarp> Is it possible to skew video by 30 degrees and place it on top of a static image with FFMPEG?
[17:19] <ubitux> yes
[17:19] <ubitux> with rotate and overlay filter
[17:22] <pa> i see there are different h264 profiles in ffmpeg, like baseline, main, high, high10, etc..
[17:22] <pa> which one is the most efficient in terms of space?
[17:23] <BtbN> Those don't come from ffmpeg
[17:23] <wintershade> pa: the newest, but it breaks compatibility with hardware players.
[17:23] <BtbN> they are the normal h264 featureset profiles
[17:24] <wintershade> pa: but the differences are minor. you should use compression presets along with the crf option (or 2-pass with target bitrate if you *really* need full control over your filesize).
[17:24] <xixi10111011> they are spec defined
[17:25] <pa> wintershade, what is the newest?
[17:28] <wintershade> pa: no idea. you should check the specs of x264. but like I said, you shouldn't really bother. from my experience, you'll get a 0,1 - 1% in filesize.
[17:29] <wintershade> pa: on top of that, if you use some really high profile and give it some moderately standard settings, you will end up with a lower profile that's only tagged as a higher one.
[17:30] <wintershade> pa: they're basically constraints for encoding options, which will enable your video to be reproduced on various hardware players.
[17:31] <pa> oh i see
[17:31] <pa> thanks
[17:31] <wintershade> pa: in other words, using (for example) baseline level 3 is practically telling the encoder "don't use bitrates or framerates that are too high for iPhone 3 to decode".
[17:32] <wintershade> pa: while, OTOH, Linux and Android will always decode practically everything. My ancient Archos Gen8 with Android 2.2 Froyo had no trouble decoding high profile level 5.
[17:33] <wintershade> pa: so if you aren't using some not-so-tolerant hardware player, don't bother. just use the settings that are best for your eyes and be happy about it.
[17:34] <wintershade> pa: what you are probably looking for are *presets*, not *profiles* (such as ultrafast, veryfast, fast, medium, slow, slower, very, placebo - or something along those lines). use one that is acceptable to you. with crf, it will have no impact on video quality, just filesize (slower presets at crf will produce smaller files).
[17:34] <wintershade> pa: HTH
[17:40] <pa> so the profile does not change the filesize as much as the preset
[17:40] <pa> interesting
[17:40] <pa> another question: does anybody here know who wrote the matroska support in libavcodecs? any chance i could have a short chat with him/her?
[17:41] <wintershade> pa: preset will impact filesize if you are using crf. if you are using 2-pass with target bitrate, it will affect quality (slower presets will give better quality - or so they say).
[17:42] <wintershade> pa: no idea about matroska. sorry.
[17:54] <roninhack> hi , anyone here ?
[17:54] <roninhack> i have a question about ffmpeg built with opencl , when i build im getting "opencl not found" error
[17:55] <roninhack> anyone here?
[18:00] <pa> hm
[18:01] <pa> maybe you miss opencl headers?
[18:01] <pa> donno because i never built ffmpeg with opencl
[18:01] <pa> also, never understood how to select the runtime
[18:01] <pa> e.g., pick between nvidia and intel, for example
[18:10] <anshul_mahe> I want to broadcast rtmp stream, is there anything else i need other then ffmpeg
[18:27] <soulless> hi
[18:27] <soulless> hi guys, I need help.
[18:28] <soulless> I try use the -hls_flags but I always get the same error Unrecognized option 'hls_flags'
[18:28] <soulless> I downloaded the last binary for OS X
[18:29] <anshul_mahe> how to stream rtmp stream to youtube
[18:31] <soulless> I try mp4 input file
[18:31] <soulless> ffmpeg -i Divergent.mp4 -hls_flags single_file out.m3u8
[18:32] <soulless> ok, sorry
[18:32] <soulless> I will
[18:33] <soulless> http://pastebin.com/j7WpNZ1c
[19:00] <anshul_mahe> do anyone know how to form youtube rtmp url
[19:00] <anshul_mahe> to stream to youtube server
[19:11] <soulless> https://trac.ffmpeg.org/ticket/3972
[19:23] <ChocolateArmpits> Is anyone familiar with metadata in MXF container ?
[20:00] <zenny1> hi, how can one crop videos vertically? If one wants to crop equal amount on both sides (left and right), one can use crop filter like crop=in_w-2*10:in_h-2*20, but if I need to crop 40 pixels on left and 60 pixes on right and none on top and bottom, what should be the above command? Thanks!
[20:00] <dahat> Are there any known 'newer' RTMP servers that spit out either RTMPE or RTMPS that libRTMP is known not to work with at this time?
[20:10] <llogan> zenny1: crop=iw-100:ih:40:0
[20:57] <benlieb> I'm chopping up a large video into many small sections. All is well except for the last video in the series. I can't hear the audio. No matter what I do, I can't seem to make this work. What am I missing?
[20:59] <benlieb> I guess it could be on my side, but I wonder if this is a common thing. Audio syncing issue?
[21:09] <benlieb> It seems it was user error. I was fading starting at -33000 seconds.
[21:09] <benlieb> bug involving times larger than one hour.
[21:09] <benlieb> in my code
[21:41] <Muthu> hello
[21:42] <Muthu> I have already UDP multicast headend support available. Now I want to take that and stream to HLS for apple devices
[22:25] <zenny1> llogan: Thanks, it worked. But the syntax is going above my head.
[22:31] <anshul_mahe> how to setup rtmp server using ffserver
[22:37] <BtbN> By using nginx instead. ffserver is dead
[22:40] <anshul_mahe> BtbN: ok,  i will try that, thanks
[23:17] <Phlarp> http://pastebin.com/hZafkine I have this command which scales and rotates a video, however the scaled video is placed directly in the middle of the output, is there anyway to control this offset?
[23:22] <Lvrbny_> Hello, I was wondering if someone might want to help out a ffmpeg noobie. I'm just trying to code some audio PCM to AAC.
[23:23] <sacarasc> Using the libraries? Or the command line?
[23:25] <Lvrbny_> i believe i'm using the cmd line
[23:25] <sacarasc> https://trac.ffmpeg.org/wiki/Encode/AAC
[23:25] <sacarasc> That should help.
[23:26] <Lvrbny_> Thanks, i'll read that and post back in a few.
[23:39] <llogan> Phlarp: you could use crop, pad, and/or overlay to move it
[23:39] <llogan> pad then crop
[00:00] --- Wed Sep 24 2014


More information about the Ffmpeg-devel-irc mailing list