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

[burek]

[01:00] <ac_slater> hey guys, I just got done reading a boat load of MISB standard documentation. They REALLY like MPEG2TS for a container that can hold audio, video, and generic data. Question is, I don't see any libavcodec examples for MPEG2TS muxing. Where should I start?
[01:02] <ac_slater> I'll ask in ffmpeg-devel
[01:02] <ac_slater> oh nevermind, their topic says I should ask here. Fair enough ;)
[02:16] <The_Ball> I'm trying to find out if a security camera puts additional information (like motion detection triggers) in the transport stream. It's a RTSP transport which ffplay reports as containing two streams:     Stream #0:0, 28, 1/90000: Video: h264 (Baseline), yuv420p(tv), 2048x1536 [SAR 1:1 DAR 4:3], 1/180000, 15.17 tbr, 90k tbn, 180k tbc and Stream #0:1, 1, 1/90000: Data: none, 0/1. Is there a way I can dump anything that is being sent in the data stream?
[02:16] <The_Ball> Or could there be KLV fields hidden in the h264 stream perhaps. Would -loglevel debug show any embedded KLVs?
[08:51] <road|runner> hi, i uses sockso streaming server and would like transcode on the fly flac to mp3. to do this i uses ffmpeg -i file.flac -vn -f mp3 -ab 320k -. in most cases this works well but some jobs are truncated.  no idea why. when using same construct in windows cmd and pipe the output diretcly to a player ffmpeg -i file.flac -vn -f mp3 -ab 320k - | vlc - nothing is truncated
[08:53] <road|runner> my flac files contain 2 streams, video (cover art) and the flac compressed audio stream
[09:00] <road|runner> i have to say sockso invokes transcoding script passing as the first parameter path and reads transcoded streams from stdout
[10:45] <kode54> weird
[10:45] <kode54> I am trying to use ffmpeg to convert from H.264 to WebM
[10:45] <kode54> and the source video has a tbc of 59.94, but appears to be entirely progressive
[10:45] <kode54> yet when I convert, the result looks like it was fed through a nasty field blending deinterlacer
[11:16] <brontosaurusrex_> kode54, vp8?
[11:16] <kode54> yes
[11:17] <Mavrik> kode54, that's usually what happens when your bitrate/quality is too low
[11:18] <kode54> I tried using -qmin 0 -qmax 25 -crf 5 -v:b
[11:18] <kode54> I assume it's bad to mix crf with v:b
[11:18] <kode54> v:b 1700k
[11:18] <Mavrik> it's pointless.
[11:18] <kode54> ah
[11:18] <Mavrik> and it probably confuses the heck out of the encoder :P
[11:18] <Mavrik> there's also a "speed" setting
[11:19] <kode54> what are the speed settings available?
[11:19] <brontosaurusrex_> last time i tryed vp8 it didn't have crf
[11:20] <brontosaurusrex_> so that must be new ...
[11:23] <kode54> wow
[11:23] <kode54> comes out bad even when I use -minrate 1700k -maxrate 1700k
[11:23] <Mavrik> afaik minrate and maxrate don't do anything with vp8
[11:23] <kode54> oh
[11:24] <Mavrik> or at least not with any good effect
[11:24] <Mavrik> even though this tells that they do: http://people.xiph.org/~j/ffmpeg.html
[11:24] <Mavrik> this gave me pretty good resuts with older vpx/ffmpeg : https://www.virag.si/2012/01/webm-web-video-encoding-tutorial-with-ffmpeg-0-9/
[11:24] <kode54> b:v is what I meant above, but yeah
[11:31] <kode54> no matter what settings I use, it ends up producing a video which is ~504kbps, including the 128kbps vorbis audio
[11:31] <kode54> do I have to specify the video codec manually?
[11:32] <kode54> it already defaults to libvpx when I specify .webm for output
[11:40] <brontosaurusrex> kode54, i can post my horrible ffmpeg|vp8 pipe commands if you wish
[11:40] <brontosaurusrex> but they are dated
[11:40] <kode54> not sure if I can build vpxenc anyway
[11:41] <kode54> http://mobile.foobar2000.com/kickstarter/kickstarter-foobar1.mp4 maybe it's the video, lol
[11:41] <kode54> I'm trying to prepare something for spoon
[11:41] <kode54> in case he doesn't want to encode his own webm format
[11:41] <kode54> he used some generous bitrate for the source video
[11:42] <brontosaurusrex> you guys are from hydrogenaudio?
[11:42] <kode54> I am
[11:42] <kode54> and somehow got hooked into working on this mobile thing
[11:43] <kode54> no idea what use I'll be
[11:43] <brontosaurusrex> yeah, i read about it
[11:44] <brontosaurusrex> seems confusing to me, but i'am more of a mobile hater, so does not matter really
[11:46] <brontosaurusrex> so do you people need a video guy? I could do that video soooo much better
[11:47] <brontosaurusrex> catch: I want shares
[11:49] <Mavrik> kode54, yeah, that looks like a type of video where encoder will refuse to increase bitrate
[11:49] <Mavrik> but the fuzzyness is interesting
[11:49] <Mavrik> do you have the latest libvpx and ffmpeg?
[11:56] <c_14> kode54: I just tried encoding the video you posted to webm with vp8 and I got 1012kb/s total and the video looks fine. Like Mavrik said, I'd check to see you are using the newest versions of ffmpeg and libvpx.
[12:00] <wickwire> Hi everyone, I was asked to investigate a solution and after much googling and since I don't know that much about it, I thought I'd ask
[12:01] <wickwire> I'm working on an RTP/RTCP server-client implementation
[12:01] <wickwire> which is working
[12:01] <wickwire> but now, I've been asked to implement a sort of "burst" mode on it
[12:01] <wickwire> meaning, upon request, the sender party should send the video over RTP,
[12:02] <wickwire> faster than playback time
[12:02] <wickwire> so that in theory, the client would have all the video as fast as possible
[12:03] <wickwire> in case the server (sender) should fall
[12:03] <wickwire> is this kind of "burst", "lazy loading" scenario possible with RTP...?
[12:04] <wickwire> I have found that if I activate buffers and caching on the client, I'm able to store the feed and if the server falls, the video still plays
[12:04] <wickwire> but that implies waiting to start streaming, to build the cache - and it won't do me any good in this case, as I also need the client to start playing the content as soon as possible
[12:05] <wickwire> does anyone have any suggestions or clarifications on this, if possible, where should I start...?
[12:05] <wickwire> thanks in advance
[12:06] <Mavrik> hmm, I haven't seen anything like that done with RTP
[12:06] <Mavrik> but that's basically how RTMP works
[12:07] <wickwire> RTMP? ok I'll have a look at it
[12:07] <wickwire> thanks
[12:09] <wickwire> RTMP seems to be proprietary
[12:09] <wickwire> does ffmpeg handle it properly...?
[12:10] <DrewM> "You can add -movflags +faststart as an output option if your videos are going to be viewed in a browser. This will move some information to the beginning of your file and allow the video to begin playing before it is completely downloaded by the viewer. It is not required if you are going to use a video service such as YouTube." <-the FFMPEG wiki article on X.264 encoding.
[12:10] <road|runner> hi, i uses sockso streaming server and would like transcode on the fly flac to mp3. to do this i uses ffmpeg -i file.flac -vn -f mp3 -ab 320k -. in most cases this works well but some jobs are truncated.  no idea why. when using same construct in windows cmd and pipe the output diretcly to a player ffmpeg -i file.flac -vn -f mp3 -ab 320k - | vlc - nothing is truncated
[12:11] <DrewM> Have oyu tried playing the truncated file in multiple players?
[12:12] <Mavrik> wickwire, it worked fine for our tests
[12:12] <DrewM> A lot of them misreport the length of veriable bitrate audio
[12:12] <Mavrik> wickwire, but it's possible RTP/RTSP could have that kind of download control
[12:12] <Mavrik> I'm a little rusty on those protocols, I've tried to avoid them as much as possible
[12:14] <wickwire> ok Mavrik, DrewM, I'll keep looking, thank you for the help
[12:15] <DrewM> It annoys me that everybody encapsulates those protocols in flash. I want the link so i can put it in a media player so I can put it on the right screen.
[12:16] <wickwire> DrewM I just read the beginning of http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol
[12:17] <wickwire> I'll have a look at what you've described, thanks again
[12:18] <road|runner> DrewM: in vlc only... but my flacs contain cover art and id3 tags, could this be an issue?
[12:19] <road|runner> stored cover art is 500x500
[12:20] <DrewM> You're right. RTMP is Adobe. But Big Media (Viacom, etc) like it so it tends to be what gets used.
[12:21] <DrewM> road|runner: It could.
[12:21] <road|runner> is there a way to filter out id3 tags before encoding?
[12:22] <DrewM> Er not ID3 tags. And I wouldn't think that cover art would either but it's a relatively new thing and I've learned to never say never.
[12:23] <jonascj> I've setup an ffmpeg->ffserver mjpeg stream. It works fine in VLC player (2-3 seconds delay) but I cannot use it in a browser. With the risk of someone in our print lab flashing the camera here goes - right now it just displays a computer screen because the camera sits on a desk: http://thecheat.colding.com:8090/webcam.mjpeg
[12:23] <jonascj> any ideas why that url does not work in a browser?
[12:24] <brontosaurusrex> jonascj, since browser has no idea on how to decode .mjpeg?
[12:25] <jonascj> brontosaurusrex: on wikipedia and tutorials you can read that mjpeg enjoys native support in many browsers... but I haven't found it so (just like you say)
[12:25] <brontosaurusrex> works fine here with mpv player
[12:26] <jonascj> brontosaurusrex: yeah, it works for me with vlc player.
[12:26] <jonascj> Now I would just like to view it in a browser but that seems to be a hard task.
[12:26] <brontosaurusrex> use something else, like light h.264
[12:26] <DrewM> It opened but it downloaded continuously. You could probaby make an HTML that includes it as part of the page.
[12:27] <brontosaurusrex> or that
[12:27] <brontosaurusrex> but what component would actually play mjpeg?
[12:27] <DrewM> No idea.
[12:27] <DrewM> But if it's there it should know what to do with it.
[12:28] <jonascj> people in #html5 say that "properly encoded mjpeg should work in <img src="host.com/webcam.mjpeg">
[12:28] <DrewM> I don't get why youtube doesn't have video in firefox without flash.
[12:28] <jonascj> they are not necessarily video wizads (neither am I)
[12:29] <jonascj> do you guys know about webm? That is suppose to work with html5's video tag
[12:30] <brontosaurusrex> jonascj, you still won't cover every browser and vp8 is pain in the ass to use, seriously i'd just use x264
[12:30] <brontosaurusrex> jonascj, then you can make flash/html5 thingy to display the video
[12:31] <jonascj> brontosaurusrex: okay, so you'd say x264 (which is mpeg4?) and then get some player (flash, html5, javascript, whatever) to play it?
[12:32] <brontosaurusrex> jonascj, yes, the idea would be to use html5 for browser that support h.264 decoding natively and flash for the rest
[12:32] <brontosaurusrex> browsers
[12:33] <jonascj> okay, thanks
[12:34] <jonascj> on another node - do you know what I would have to read up on if I wanted ffmpeg to just push single jpegs to a custom server / distributor application I would write?
[12:34] <jonascj> *note
[12:34] <DrewM> FF got native X264 decoding just a few months ago.
[12:34] <jonascj> Is it called streaming if you just transmit one whole jpeg after another, and on the receiving end push them along to some javascript which will then render them?
[12:35] <DrewM> So I'm not sure what doesn't support it by now... TOR users?
[12:35] <jonascj> DrewM: but does that work with live streaming also or just treaming of static files?
[12:38] <DrewM> It seems most are still using flash right now but i'm not sure what the future will hold. I don't even know if HTML5 has stuff for streaming in it or not. I'd think that it does but haven't looked yet.
[12:39] <DrewM> Regardless there's a lot of cases where people use flash applets where they don't need to. There's a handy greasemonkey script I've been using lately called Linternamagica that tries to grab the MP4/webm resource out of the flash code and put it in the browser's standard videoplayer object. I love it muchly.
[12:40] <jonascj> I think I'll give webm a chance. It seems to work with the major browsers (latest versions) and the <video> element
[12:41] <jonascj> It might be some work compiling ffmpeg to have the right libraries and afterwards some work finding the right ffserver config for it.
[12:42] <DrewM> Webm only accepts ogg vorbis so your audio will most likely need to be transcoded. Though you were probably going to transcode to aAC for MP4 anyway.
[12:43] <DrewM> The x264 wiki has stuff on webm transcoding. I dont' remember how much of it talks about streaming though.
[12:43] <DrewM> Er, ffmpeg wiki I mean
[12:43] <DrewM> durp
[12:44] <azk> I recently set that up with ffserver
[12:44] <azk> Works fine with chromium/webkit
[12:44] <azk> No sound on firefox atm
[12:44] <DrewM> Webm should have FLAC as an option IMO. Even if nobody uses it. I suppose no one's calling webm an HD codec so I suppose that's never gonna happen.
[12:44] <JEEB> webm is just a subset of matroska
[12:45] <c_14> webm also has opus if you -strict -2
[12:45] <c_14> But opus support isn't everywhere yet, sadly.
[12:45] <JEEB> not sure if the opus output that ffmpeg does is correct :s never checked if they fixed it
[12:46] <DrewM> That would make it an amazing option for a VOIP program.
[12:46] <JEEB> anyways, too bad libvpx is bad :P
[12:46] <JEEB> with both vp8 and vp9
[12:47] <DrewM> See i like Metroska a lot because you can mux anythign to it and it doesn't care. Whereas Webm has 1 codec for video and 1... apparently 2 for audio. So it's like Metroska accept with all the useful bits taken out?
[12:47] <JEEB> it's more or less got two video and two audio formats atm
[12:47] <JEEB> vp8 and vp9 for video
[12:47] <JEEB> vorbis and opus for audio
[12:47] <DrewM> I forget about VP9.
[12:48] <DrewM> Still.
[12:48] <c_14> webm was built around free formats, precisely so you can implement it in any browser without having to pay royalties
[12:49] <DrewM> Which is really cool if you make browsers!
[12:50] <c_14> It's really cool if you're making anything where you want to use video/audio without having to pay royalties.
[12:50] <JEEB> vp9 kind of had a chance since as a format it is better than AVC, but too bad google doesn't seem to want anyone to use it :P
[12:50] <JEEB> the encoder is slow as molasses and they're not interested in multithreading it either
[12:51] <JEEB> also the on2 style of format development is still active as it was probably with vp8 when it was within on2, everything's behind closed doors and there's no specification
[12:51] <JEEB> the implementation _is_ the specification
[12:52] <DrewM> Right. *I* understand that webm is better legally. But I don't need to, I don't make content.
[12:52] <JEEB> uhh
[12:53] <JEEB> just call the actual a/v formats instead of "webm"
[12:53] <JEEB> it's a container for eff's sake (subset of matroska)
[12:55] <DrewM> IMO, A container format that can only contain 2 possible codecs for A/V is not very useful. Were either of these codecs a defacto video standard this would be less of an issue, but I dont' see VP8 many places outside youtube.
[12:56] <JEEB> It's used in some places, generally around freetards. It helps that AVC delivery for free on the internets is not needing of a license.
[12:56] <DrewM> And if people aren't using it they don't know about it and thus continue not using it.
[12:57] <JEEB> basically, libvpx with vp8 encoding is slower and gives worse results on the same average rate than libx264, thus not many actually want to use it :P
[12:57] <JEEB> VP9 would be actually a useful way of getting people to use such a format... but google is totally missing the chance with the implementation
[12:57] <JEEB> because the goddamn encoder is _slow_
[12:58] <JEEB> like, when your encoder is in a similar ballpark as the HEVC reference encoder, you're doing it wrong
[12:58] <DrewM> Yeah, sorry--I really mean "apart from web page embeds" but if YT didn't roll it out I really don't think it woudl be used nearly as much as it is.
[12:58] <JEEB> (I know that libvpx is generally speaking a reference implementation as well, but it's actually also meant for end-users :)
[12:59] <JEEB> also 4chan recently started letting people uploading vp8 webm clips as an alternative for gifs
[12:59] <JEEB> which kind of pushed interest, but I really dunno... :s
[12:59] <DrewM> I haven't kept up with VP9. Is there just the one encoder for it?
[13:00] <JEEB> yes
[13:00] <JEEB> pretty much just like with VP8
[13:00] <DrewM> Is it opensourced like 8?
[13:00] <JEEB> yes
[13:00] <DrewM> So if Google's dragging its feet couldn't someone else fork it?
[13:00] <JEEB> well
[13:00] <JEEB> the problem is that there's the HEVC format
[13:00] <JEEB> which is an actual standard
[13:01] <JEEB> and the OSS implementations around it are already ending up better :P
[13:01] <JEEB> I mean, ~10x slower than x264 is already not bad, considering the specification was finished in 2013
[13:01] <DrewM> So it's MP3 round two. That's alright with me
[13:01] <JEEB> (same as with VP9, which was in June or so of 2013)
[13:02] <JEEB> so basically the lack of interest for VP9 comes from the fact that it isn't currently already somewhat usable, and if people wanted to contribute to something they usually pick the thing that's similar and furthest away
[13:02] <JEEB> from the starting point
[13:02] <JEEB> and given that VP9 is only cared about by Google and Google alone...
[13:03] <DrewM> Right, I see. And 2 years from now everyone's already got their content stable and won't want to transcode.
[13:03] <JEEB> as I already noted, if Google had tried to push the encoder to at least be in a similar ballpark as the least bad HEVC encoders
[13:03] <JEEB> they would have had an actual chance
[13:04] <JEEB> since firefox and chrome already have support for decoding
[13:04] <JEEB> and HEVC is not yet deployed anywhere in the web except for divx's crappy plugin
[13:04] <JEEB> makes me sad :P would have been a switch, and actual progress from AVC
[13:04] <DrewM> I'm still puzzling out the politics of the move to open source those formats. What do they get out of having people use their video format when they already have the world's most popular video sharing service?
[13:05] <DrewM> Forgive me if I'm asking dumb questions that everyone knows the answer to already
[13:05] <jonascj> video is hard
[13:06] <JEEB> I don't think anyone here can say for sure what Google was/is trying with the acquisition of On2, but I'm pretty sure it has at least partially to do with people having to use their stuff, instead of other people's stuff
[13:07] <ubitux> i'd they don't need people to be able encode in vp9; they just needed vp9 to lower the bw cost from yt, and they need the codec to be opensource so the decoder is available everywhere
[13:07] <ubitux> i guess that's all there is :p
[13:07] <ubitux> i'd *say*
[13:08] <DrewM> Right but they already have market dominance. They can switch youtube over to webm and kill X264 and watch the browsers scramble to suddenly implement VP9 because they can't watch their favorit musical cat videos. Since so many people are on youtube it accomplishes a similar thing with much less of a concession.
[13:09] <DrewM> Er, I mean kill their use of it on youtube, not everywhere, obviously
[13:09] <JEEB> x264 is an implementation, not a format
[13:09] <JEEB> just FYI
[13:09] <JEEB> the format can either be called AVC or H.264
[13:10] <JEEB> (the ISO and ITU-T names)
[13:11] <DrewM> Sorry. I do sort of know that but use them interchangably in my own head anyway.
[13:13] <DrewM> I also know there is much more to the scene than YT, but no browser is going to let the users just not have access to it. Or everyone will just switch to Chrome and abandon them.
[13:21] <jonascj> For really slow webcam feeds (1-5fps) could one capture single jpeg and push to distribution which would serve them to some "viewing / rendering application" (javascript which just renders each frame as it arrives)?
[14:15] <anshul__> how to check vlc is compiled with ffmpeg
[14:15] <anshul__> I want to apply break point on any function of vlc
[14:25] <superc2_> hi. still trying to get a basic setup running with ffmpeg... just reinstalled everything and took the sample ffserver.conf file from the sources... however I'm still not able to see anything.
[14:26] <superc2_> so basically I'm trying to stream my webcam with vlc from a windows machine to the ffserver and then from there back to a windows media player
[14:27] <superc2_> for vlc... is rtsp streaming the right option?
[14:38] <superc2_> anyone there?
[14:38] <superc2_> if the connection status is in State "WAIT_FEED" the transmission from vlc to the server does not work, right?
[15:34] <Mavrik> hmm
[15:34] <Mavrik> do we have a barrel distortion filter in ffmpeg yet
[16:20] <Voicu> hello
[16:21] <Voicu> I'm trying to decode a (maybe) broken aac stream
[16:21] <Voicu> and I get errors of the form "channel element x.x is not allocated"
[16:21] <Voicu> what does that mean? what is actually missing?
[20:19] <bakers> Does ffmpeg default to using vp8 or vp9 for .webm titled files?
[20:20] <c_14> vp8 afaik
[20:20] <bakers> how do I specify vp9 vs vp8 on the CLI?
[20:20] <c_14> -c:v vp9
[20:20] <bakers> c_14: That's too easy :)
[20:20] <bakers> ok
[20:21] <c_14> You might want to read: https://trac.ffmpeg.org/wiki/vpxEncodingGuide
[20:21] <c_14> It doesn't have everything, but it's useful.
[20:23] <c_14> You can also look at ffmpeg -h muxer=webm and ffmpeg -h encoder=vp9
[20:27] <bakers> is there a long hand form of -c:v ?
[20:27] <bakers> --codec:video ?
[20:28] <c_14> There's -codec:v
[20:29] <bakers> "-codec:video" appears to work
[20:29] <bakers> Thanks
[20:30] <c_14> np
[21:00] <haptiK> hi c_14
[21:01] <c_14> hi
[21:16] <pzich> so...I'm trying to H.264 encode a video that's 5760x1200 at 30, and I'm getting garbled results. The internet is suggesting that this is just way too big for H.264 to handle, am I just SOL?
[21:45] <JEEB> pzich, H.264 with libx264 should encode that just fine, as long as you make sure it doesn't go out of address space :P
[21:46] <JEEB> regarding decoding, that /should/ be fine too, given that height is even less than 3840x2160
[21:46] <JEEB> which is decoded just fine by recent enough lavc
[21:46] <JEEB> basically, I recommend a 64bit build of a recent enough libx264 for the encoding part
[21:48] <c_14> Just a note of warning though, I just tried upscaling one of my videos to 7680x4152 for testing purposes and my computer crashed.
[21:48] <JEEB> probably a different reason for that :P
[21:49] <pzich> I've not had any crashes, but the output video is not looking write, uploading screenshots and command now
[21:49] <JEEB> pzich, what have you tested it with?
[21:49] <pzich> I'm viewing with Quicktime 7 and VLC.
[21:50] <JEEB> ok, QT is known to derp
[21:50] <JEEB> what OS are you on?
[21:50] <pzich> yeah :/
[21:50] <pzich> OS X
[21:50] <JEEB> go grab an mpv build
[21:50] <JEEB> and check with it
[21:50] <c_14> >ffmpeg invoked oom-killer: [..]
[21:50] <JEEB> http://mpv.io/installation/
[21:50] <c_14> Then x died and ...
[21:50] <JEEB> c_14, yes -- if you start using a lot of RAM and you don't have it or swap, then suddenly linux starts killing things :)
[21:51] <JEEB> pzich, scroll down to the OS X part basically
[21:51] <pzich> JEEB: will take a look, thanks
[21:52] <JEEB> it's a command line player, but the binaries should be built with new enough stuff
[21:53] <JEEB> anyways, in cases like this it's better to provide a sample of the encoded stuff, rather than screenshots. that way you can also have others look how it looks for them in their things :P
[21:53] <JEEB> but the command line and the full terminal output would be helpful
[21:54] <pzich> yeah, I'm actually thinking this is QT7's fault, and this encode is an intermediate step for another program to interpret, so I'm going to poke at that a bit.
[21:54] <pzich> Also, I'd be willing to share, but it's currently still semi-confidential material.
[21:54] <JEEB> yeah, you generally can test with similar - even generated content, and see if that looks the same
[21:55] <JEEB> and then post that
[21:55] <JEEB> just for future reference
[21:55] <pzich> yeah, I'm going to try knocking out something at the same size and encoding as the source if I can't get this working in the next ~15m
[21:55] <pzich> thanks for the help thus far
[21:58] <phelix> for some reason with my video player the audio tends to face in and out and in and out again on some videos.. Is there a type of audio opions I could use when converting a video that might prevent this from happening?
[22:01] <pzich> phelix: could you create a paste with the command you ran that you're seeing this issue, and the ffmpeg output for the encode?
[22:14] <phelix> ffmpeg -i ./video.mp4 -preset veryfast -vf scale=854x480 -aspect 16:9 -vcodec libx264 ./video.mp4
[22:14] <phelix> i mean ffmpeg -i ./video.mp4 -vf scale=854x480 -aspect 16:9 -vcodec libx264 ./video.mp4
[22:19] <phelix> this is happening on the orignal video and the converted one. It may be my player. But i am wondering if there is another route i can try to encode with on the audio that might help this problem
[00:00] --- Tue Apr 29 2014