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

[burek]

[00:22] <grepper> burek: seems you need -copyts for that trick to work with -ss before AND after input
[00:24] <grepper> (from  elenril on #libav)  He said otherwise the timesets get reset with -ss after input.  Seems to work okay also if you do  -ss 10 -i input -ss 2  to get to the 12th second.
[00:30] <grepper> hm, that frame is a fraction off the one with copyts though
[01:51] <_hc> I'm trying to run an audio and video filter at the same time on a single file, and am failing.  anyone have an example of how to do this?  I've tried the lavfi approach and -filter:a and -vf
[01:51] <_hc> I'm using ffmpeg 0.10.4
[01:51] <_hc> on Linux Mint, built from source
[05:24] <djames04> I'm looking for a crystalbuntu room& does anyone know of one?
[06:36] <SubJunk> I can't seem to get rid of these endless "buffer underflow" errors when converting x264 to mpeg2video. Any tips?
[06:40] <grepper> best to show your command line to get a response
[06:47] <SubJunk> Here's what I've been trying: ffmpeg -i input.mkv -c:v mpeg2video -f vob -c:a ac3 -g 1 -q:v 1 -qmin 2 -ab 640k -threads 8 -bufsize 140000000 -maxrate 140000000 output.mpeg
[06:48] <zap0> SubJunk, output your broken x264 to a unbreakable format.  then re-encode that to mp2
[06:48] <SubJunk> I've tried lots of different values for bufsize and maxrate
[06:49] <SubJunk> zap0: it isn't broken x264, it happens with good scene releases too
[06:50] <SubJunk> Also the -f vob part looks strange but if I remove it it breaks device compatibility (PS3 doesn't recognise the stream)
[06:50] <zap0> ok, you just tell yourself whatever you want to believe.    im sure the tool can be persuaded to see your point of view.
[06:51] <SubJunk> Trolling or serious?
[06:51] <zap0> trolly words, serious facts.
[06:52] <SubJunk> There are over 12 million users of my program and every one of them gets the same results on any file, so it is not file-specific
[06:53] <SubJunk> Any 720p+ mkv file I should say
[06:56] <zap0> you asked all 12 million?
[06:56] <zap0> everyone of them?
[06:57] <zap0> i'll find it hard to take your circumstantual evidence into account when you exagerate.
[06:58] <SubJunk> Obviously just a troll. Hopefully someone else can reply to prevent this from becoming any more off-topic
[06:58] <zap0> perhaps try downgrading to older versions of ffmpeg,  (at least for testing)
[06:59] <SubJunk> Thanks for the suggestion. I've tried it and it was the same for the old ones too
[06:59] <SubJunk> Tried both new and old zeranoe and Sherpya builds
[06:59] <zap0> so if you say ffmpeg is ok.   the input video is OK,   what is left?    some assumption you're makng?
[07:00] <zap0> for each argument you pass, write down:   why i chose it, and why i believe it to be right.
[07:00] <SubJunk> I assume there is some error in my command line that can be corrected
[07:01] <zap0> "why?"  the fuck out of everything you have done, keep "why?"-ing it until you get to some truth.
[07:02] <zap0> try exagerting each of your arguments to produce a different set of results, that might hint at the issue
[07:03] <SubJunk> I chose mpeg2video for high compatibility with devices, -f vob for the same reason like I said above, ac3 and 640k bitrate for compatibility, -g, -q:v and qmin to get good quality, threads is obvious, bufsize and maxrate are the ones i'm really guessing at because without them ffmpeg tells me to add them
[07:07] <zap0> start with those two then.   try some different values
[07:07] <zap0> do some googling, find some examples... get a feel for what the average others use is
[07:08] <SubJunk> I've tried quite a few examples via Google and none affect it
[07:16] <grepper> dvd compatible bufsize is 224Kib, dunno much else about it
[07:21] <SubJunk> The messages are caused by -ab 640k. Same thing if I use -b:a 640k. Is there a better way to specify AC3 bitrate or is that it?
[09:51] <SubJunk> fflogger: Thanks for the tip. Here is the output without 640k specified http://pastebin.com/3JFkGddB and here is with it http://pastebin.com/kWyEFeUq
[10:11] <burek> SubJunk, try removing "-g 1"
[10:13] <SubJunk> burek: Thanks for the suggestion. It still happens after removing it
[10:17] <burek> SubJunk, what did you want to achieve with this: -bufsize 7000000 -maxrate 54000000
[10:19] <burek> because in the output, I see this: Output #0, mpeg, to 'output.mpeg': Stream #0:0(eng): Video: mpeg2video, yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s,
[10:19] <burek> 200 kbps
[10:22] <SubJunk> burek: I'm not too sure about bufsize, I just used a value that I use for MEncoder that has been stable for me. Maxrate is at that value to ensure a smooth stream over a wired connection
[10:22] <burek> -g 1 will make every frame keyframe, so I'm not sure if you really want that, combined with specifying the compression parameters like -maxrate
[10:23] <burek> also, isn't -ab 640k a little bit too much?
[10:24] <burek> did you mean 64k
[10:24] <SubJunk> 448-640k is normal for 5.1 AC3
[10:25] <burek> well, take a look at your input audio
[10:25] <burek> Stream #0:1: Audio: ac3, 48000 Hz, 5.1(side), s16, 384 kb/s (default)
[10:26] <burek> it's already ac3
[10:26] <burek> why recompressing?
[10:26] <burek> why not -c:a copy?
[10:26] <SubJunk> Thanks for the tip about -g 1. I could change it to 25
[10:27] <SubJunk> You're right that c:a copy would be better and we will do that in the future, but for now I just want a "dumb" option as a catchall, so that just in case a user inputs a 640k file they won't lose quality
[10:28] <burek> Also, looking at the output for video (200 kbps), it seems your encoding options are interfering with each others
[10:28] <burek> -q:v 1 -qmin 2 with rate limit
[10:28] <burek> so you could read more about mpeg2video encoder's options I guess
[10:28] <burek> to get an idea what you actually want
[10:29] <burek> and, if your users input a 640k file, they will still not lose any quality using -c:a copy :)
[10:30] <SubJunk> Yes but they will also be inputting other audio codecs, but I always want to output AC3 for device compatibility
[10:32] <SubJunk> I'm not sure why it is reporting that it is outputting 200kbps. The output file is 8,539 Kbps video
[10:33] <SubJunk> With a maximum bitrate of 54,000 Kbps
[10:35] <burek> I don't know mpeg2video encoder that much, I mostly use libx264 :/
[10:36] <SubJunk> Fair enough, I wish I could use that too
[10:37] <SubJunk> Well I do use it personally but can't for this because I need realtime transcoding on even slow computers
[10:38] <burek> out of curiosity, why do you need such a requirement?
[10:39] <burek> (btw, check your cpu/memory while ffmpeg is running, it might be a slow cpu so that would explain frame dropping)
[10:42] <SubJunk> I develop a program called Universal Media Server (http://www.universalmediaserver.com/) which takes any input file on the computer and outputs it to any DLNA-capable device in a format it can use. We've relied mostly on MEncoder for years but with nearly-inactive development it seems time to rely more on FFmpeg
[16:11] <dougle> "Unable to find a suitable output format for 'libvorbis'" does anybody know what format i should be passing in?
[16:11] <dougle> tried -f vob as a guess but no difference
[16:11] <Tjoppen> ogg?
[16:11] <dougle> tried that too
[16:12] <dougle> ffmpeg -y -i invid.mp4 -threads 4 -r 25 -vcodec libtheora -b:v 512k -acodec libvorbis -b:a 128k -ac 2 -ar 44100 outvid.ogv
[16:35] <BlueAidan> would a dev be able to shed some light on http://bugs.musicpd.org/view.php?id=3473 ? I ask just because I noticed that ffplay doesn't seem to have the same issue.
[16:35] <BlueAidan> there isn't apparently an osx audio driver maintainer for mpd any more
[16:50] <Mavrik> dougle: your ffmpeg probably isn't compiled with vorbis support
[16:54] <dougle> it has --enable-libvorbis using relaxed Linux.Encoding.install.sh script
[16:54] <dougle> i see libvorbis and vorbis in the -codecs output
[16:55] <dougle> would that conflict?? (<- clutching at straws)
[16:55] <Mavrik> not really
[16:55] <Mavrik> that actually means things should work
[16:55] <Mavrik> dougle: can you please paste whole output with command line included?
[16:56] <dougle> yes will update gist
[17:02] <dougle> Mavrik: https://gist.github.com/3136714
[17:03] <dougle> thanks for looking at this Mavrik
[17:03] <Mavrik> hm, sec
[17:04] <Mavrik> wierd
[17:04] <Mavrik> my ffmpeg works with your command line O.o
[17:04] <dougle> ah well that is something
[17:04] <dougle> not a param screw up on my part
[17:05] <dougle> i will reinstall libvorbis? do you think that will help
[17:05] <dougle> or is the problem within ffmpeg do you think?
[17:05] <Mavrik> dougle: you're running it from a different prefix
[17:06] <Mavrik> can you please run ldd on ffmpeg executable
[17:06] <Mavrik> and check if there are any libraries it can't find?
[17:06] <dougle> will do
[17:06] <Mavrik> also, you can try forcing output format with "-f ogg"
[17:06] <Mavrik> ffmpeg not being able to find libvorbis.so could be the cause of that problem
[17:07] <dougle> :D libvorbis.so.0 => not found
[17:08] <dougle> is copying libs from the alt prefix to /usr/lib64/ a bad thing to do?
[17:08] <Mavrik> well
[17:09] <Mavrik> setting LD_LIBRARY_PATH when running is usually a better idea
[17:09] <Mavrik> so you don't conflict with it
[17:09] <dougle> ok cheers
[17:11] <Mavrik> don't forget to run "ldconfig" if you're gonna copy stuff to lib64 or other system-wide dirs... I've wasted hours because I forgot to update library cache :P
[17:12] <dougle> yeah same, thanks for the reminder
[17:15] <dougle> there is bash script /root/Linux.Encoding.install/bin/ffmpeg which has LD_LIBRARY_PATH correctly set
[17:15] <dougle> that calls the real ffmpeg binary
[17:15] <dougle> so that is already set...
[17:18] <Mavrik> hrm~
[17:21] <dougle> copying libvorbis to /usr/lib produces same error
[17:22] <dougle> will force with -f ogg
[17:23] <dougle> .... -acodec libvorbis -b:a 128k -ac 2 -ar 44100 -f ogg .... gives same error
[17:23] <dougle> is -f position dependant?
[17:32] <Mavrik> dougle: if ldd doesn't find "libvorbis", "-f" won't help you
[17:32] <Mavrik> you need to fix your linux to find that lib :)
[17:51] <Onionnion> can I have some help with what command to use? I have an interlaced .MTS video and whenever I try to convert and deinterlace it also ends up with duplicate frames
[17:52] <burek> BlueAidan, did you try asking in #ffmpeg-devel ?
[17:54] <dougle> Mavrik: bizarrely just passing -acodec libvorbis works fine :o
[17:55] <dougle> without rates channels or vcodec params
[17:55] <Mavrik> huh
[17:55] <Mavrik> that shouldn't work :D
[17:57] Action: dougle steps away, doesn't touch a thing
[17:57] <Mavrik> ^^
[18:00] <Onionnion> burek, I'm trying to use something like this, http://pastebin.com/iD0qNL4c
[18:02] <Mavrik> Onionnion: "yadif=1" tells yadif filter to output one frame for each interlace field
[18:02] <Mavrik> meaning you get twice the number of full frames on the output as you do on the input
[18:02] <Onionnion> ah
[18:02] Action: Onionnion is still quite a ffmpeg newbie
[18:02] <Mavrik> http://libav.org/libavfilter.html#yadif
[18:02] <Mavrik> Onionnion: you can use yadif=0
[18:02] <Onionnion> I'm mostly trying to deinterlace
[18:02] <Onionnion> oh that was typo I think actually
[18:02] <Onionnion> meant -
[18:02] <Mavrik> which will cause it to output a single frame for interlaced field pair :)
[18:03] <Onionnion> 0*
[18:04] <Onionnion> ugh, but I can't get this to work
[18:04] <Onionnion> it keeps things -s 1920x1080 is an output file
[18:04] <Onionnion> thinking(
[18:04] <Onionnion> *
[18:11] <dougle> Mavrik: it seems libvorbis only likes floating bit rates
[18:11] <dougle> my -b:a param was throwing it off
[18:11] <dougle> giving that error
[18:14] <burek> dougle, you might use gdb or valgrind or some other debugger to see what is actually being loaded
[18:14] <burek> and why does it work at all if you really wanna know :)
[18:15] <dougle> i'll continue investigations after work :)
[18:16] <dougle> starting to think it's wonky configure switches for libvorbis
[18:19] <Onionnion> Mavrik, I still get duplicate frames, though
[18:28] <Onionnion> is there a command or way to remove duplicate frames?
[18:35] <Mavrik> Onionnion: use "-r" to set framerate to half of what you have on input
[18:44] <grepper> burek: did you see my message from last night re the -ss option ?
[18:44] <burek> grepper, I didn't sorry :/ I was rebooting my machine due to some upgrade
[18:44] <burek> s
[18:44] <grepper> burek: seems you need -copyts for that trick to work with -ss before AND after input
[18:45] <grepper> (from  elenril on #libav)  He said otherwise the timesets get reset with -ss after input.  Seems to work okay also if you do  -ss 10 -i input -ss 2  to get to the 12th second.
[18:45] <grepper> hm, that frame is a fraction off the one with copyts though
[18:45] <burek> timesets?
[18:46] <burek> timestamps perhaps?
[18:46] <burek> well, I've used -ss 10 -i ... -ss 14 to get to the 14th second
[18:46] <grepper> hm
[18:46] <burek> and it worked, so I really don't know what to say..
[18:46] <burek> which version of ffmpeg you were using
[18:47] <grepper> I'm doing it on a dvd compatible mpeg2
[18:47] <grepper> sec
[18:47] <grepper> ffmpeg version 0.11.1
[18:48] <grepper> just trying to see if there is a way to do it that will be mostly backwards compatible so I can get rid of using transcode for fast seeking in my program :)
[18:48] <grepper> would always using -copyts cause any problems for your version ?
[18:49] <burek> well, it mostly depends on the gop size
[18:49] <burek> i.e. how often there are I-frames in the input
[18:49] <burek> I'm afraid there is no "general" command that will cover most of your needs
[18:49] <grepper> hm, okay
[18:49] <grepper> thanks
[18:50] <grepper> I tried a long seek using your method and it was very slow and didn't seem to finish
[18:50] <burek> first -ss uses those key frames for fast seeking (I guess) and latter -ss (after -i) uses frames that passed through the decoder
[18:50] <burek> so all the frames should have same timestamps
[18:50] <grepper> seems like it 'should' work :)
[18:51] <burek> because decoder wouldn't change them (I don't see no reason for that)
[18:51] <burek> that might be because you missed the key frame
[18:51] <burek> or something
[18:51] <burek> make sure you find out where exactly is some key frame and try -ss before it and -ss after it
[18:51] <grepper> I think -ss N -i always seeked to the keyframe
[18:51] <burek> just for a test
[18:52] <burek> yes but
[18:52] <burek> if the key frame is at 14th sec
[18:52] <burek> and you type: ffmpeg -ss 15 -i input -ss 16 ...
[18:53] <grepper> -ss 01:29:30  -copyts -i FILE -ss 00:00:30  ... finished almost immediately and got the frame at 01:30:00
[18:53] <burek> it will skip to the key frame after 14th second (who knows where) if it relies on the first -ss
[18:53] <burek> but the 2nd -ss tells that it should seek into 16, so, I guess you get all of the seeking using just the 2nd -ss
[18:53] <grepper> I could find tune it so that it only comes into play if the seek in longer than a certain length
[18:54] <grepper> what is the maximum gop length that most standard formats use ?
[18:54] <burek> :D
[18:54] <burek> you tell me :D
[18:54] <grepper> heh
[18:54] <grepper> I thought a minimum of 5 seconds would be enough, guess not
[18:55] <burek> well I've seen -g 250 @25 fps
[18:55] <grepper> ie, seek to 10, then -ss 5 to get to 15 for example
[18:55] <burek> which gives 10 sec
[18:55] <grepper> even using 10 would be a help for long seeks
[18:55] <burek> well, the main idea is that a keyframe should be in between those 2 -ss
[18:55] <burek> :)
[18:56] <burek> I usually did it manually all the time
[18:56] <burek> so I could fine tune my free time spent on it :D
[18:56] <grepper> if they are seeking less than 20 seconds then the slow seek is not so painful and I could use it.  But if seeking to 01:30:00 it would be a great help
[18:56] <burek> but if you want to automate it, well.. I don't know really how it should be done properly
[18:56] <grepper> so I could increase the value considerable
[18:57] <grepper> considerably
[18:57] <burek> well, get the length in minutes and do something like $time mod 5minutes
[18:57] <burek> so you always have max 5 minutes to seek into with 2nd -ss
[18:58] <grepper> 5 minutes ?  That seems pretty long.  Can gop really be that large ?
[18:58] <burek> I don't know :)
[18:58] <grepper> heh
[18:58] <burek> there are really weird people out there ^^
[18:58] <grepper> well, I think it would be a great feature to add - using -ss N -i FILE -ss N is not a bad syntax
[18:58] <grepper> :)
[18:59] <grepper> its amazing it can't be done now, but given the tower of babble of formats, maybe not so amazing
[19:00] <burek> well, honestly, maybe it should be a better idea to suggest an enhancement on bug tracker
[19:00] <grepper> okay
[19:00] <grepper> burek: are you an ffmpeg dev ?
[19:00] <burek> nope
[19:00] <grepper> well your help pages are very useful, thanks for your time
[19:01] <burek> :beer: :)
[19:01] <grepper> I would but I see you drink quite a bit already, so don't want to add to your habit :)
[19:02] <burek> :))) it's healthy :) has got some vitamins b12 in it :))
[19:43] <Freakshow> w00t... back
[20:07] <arcanescu> through ffplay is there a way to stop concealing errors?
[20:31] <arcanescu> I am getting alot of RTP: missed packets.... i read around on forums is there a solution for this problem yet? ... my stream is an rtsp h264 encoded stream over udp
[20:39] <Freakshow> command line? pastebin of error output?
[20:40] <arcanescu> one second
[20:41] <arcanescu> http://pastebin.com/13MvpPWb
[20:41] <arcanescu> commandline ffplay -i "rtsp url"
[22:13] <tmatth> can anyone confirm this bug? https://bugzilla.rpmfusion.org/show_bug.cgi?id=2423
[00:00] --- Thu Jul 19 2012