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

[burek]

[13:36] <SegFaultXavi> Hello! I am trying to make some profiling of ffmpeg's DECODING performance. Can I use the "ffmpeg" or "ffplay" tools for this? with what command line?
[13:37] <SegFaultXavi> I do not want to measure the time spent memcpy'ing the decoded frames into video memory, so I would need to shut off any video display
[13:37] <JEEB> ffmpeg should be able to do it
[13:38] <SegFaultXavi> to what output format? I do not see "raw" in the list
[13:38] <JEEB> video has rawvideo, audio has tons of stuff
[13:38] <JEEB> ffmpeg -i welp.input -map 0:TRACK_TO_BENCH -f null -
[13:38] <JEEB> I guess this actually should do?
[13:38] <JEEB> no need for rawvideo
[13:39] <JEEB> oh right
[13:39] <JEEB> -c:v ravideo
[13:39] <JEEB> *rawvideo
[13:40] <SegFaultXavi> awesome, thanks :)
[13:40] <SegFaultXavi> pretty fast decoding we have here :D
[13:40] <JEEB> ok, just tried with a file with a video and audio track and that seemed to do "the right thing" for the both selected-by-default tracks
[13:41] <JEEB> also you can play with the selected amount of threads before -i
[13:41] <JEEB> (sets threads for decoding)
[13:41] <SegFaultXavi> what is the default? seems to be using all cores without that option
[13:42] <JEEB> by default it sets some sane'ish value
[13:42] <JEEB> depends on the decoder tho
[13:43] <SegFaultXavi> ok, wasn't using all cores
[13:44] <SegFaultXavi> I can't see the option to set the amount of threads...
[13:45] <JEEB> -threads NUMBER IIRC
[13:45] <JEEB> http://ffmpeg.org/ffmpeg-all.html
[13:45] <JEEB> and you can set them per-decoder in case you are decoding more than one track
[13:45] <cbsrobot> there is also a -benchmark swtich
[13:46] <JEEB> -threads:NUMBER_OF_TRACK NUMBER_OF_THREADS
[13:46] <SegFaultXavi> yeah, you're right, I needed "-help full" :)
[13:48] <SegFaultXavi> cbsrobot: thanks, -benchmark seems to produce the same figures as "time ./ffmpeg ..."
[13:48] <cbsrobot> I thought it also showed some memory related figures
[13:48] <cbsrobot> an there seems to be a -benchmark_all switch
[13:49] <cbsrobot> I never used them though
[13:51] <SegFaultXavi> I am only interested in times as of now
[13:51] <SegFaultXavi> thanks a lot guys!
[14:27] <chele> Hello all! How are you doing? I have some problems trying to extract the A/V streams from 3gp container. The issue is with the video streams. I execute the following command from statically build ffmpeg: ./ffmpeg -i input.3gp -y -an -vcodec copy rawvideo.h263. Inspecting after that the video stream I can confirm that the frame rate is different from the rate I see when I inspect the input.3gp.
[14:28] <chele> Im using this build: ffmpeg version N-58485-ga12b4bd built on Nov 27 2013 05:33:38 with gcc 4.6 (Debian 4.6.3-1) configuration: --prefix=/root/ffmpeg-static/64bit --extra-cflags='-I/root/ffmpeg-static/64bit/include -static' --extra-ldflags='-L/root/ffmpeg-static/64bit/lib -static' --extra-libs='-lxml2 -lexpat -lfreetype' --enable-static --disable-shared --disable-ffserver --disable-doc --enable-bzlib --enable-zlib --enable-postproc --e
[14:28] <chele> e-libx264 --enable-gpl --enable-libtheora --enable-libvorbis --enable-libmp3lame --enable-gray --enable-libass --enable-libfreetype --enable-libopenjpeg --enable-libspeex --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-version3 --enable-libvpx
[14:29] <JEEB> chele, you shouldn't expect timestamp information to live through if you extract a video stream into a raw bit stream
[14:29] <JEEB> for most formats you will just get a random default value for "frame rate" in such a case
[14:30] <relaxed> I believe you can define the correct framerate when muxinga raw stream.
[14:31] <chele> JEEB: I see.
[14:31] <JEEB> relaxed, whether or not that works correctly depends on a whole lot of stuff
[14:31] <chele> relaxed: Yes. I cannot get it work. In the end I get different bitrate.
[14:32] <chele> So I can't get it as the original one.
[14:32] <JEEB> I think relatively recently muxing raw H.264 into, say, mp4 led the timestamps to be as if there were no out-of-order pictures
[14:32] <JEEB> (b pictures)
[14:35] <chele> So Is there a way to achieve my purpose. Split A/V from 3gp container (amr,h263) into raw streams. Transmit them from machine A to B. In the B machine I merge those two and that merged 3gp file should the same as the original or at least the configuration of the A/V codec should be the same.
[14:35] <chele> So that I can playback the "new" 3gp file.
[14:36] <relaxed> chele: shouldn't happen if you stream copy: ffmpeg -framerate $framerate -f $format -i input -c:v copy output.3gp
[14:40] <JEEB> I just recommend that unless you really need to have the stuff as raw streams, don't use raw bit streams
[14:40] <JEEB> or do keep the timestamps SOMEWHERE
[14:43] <chele> JEEB: I don't know well the h263 codec but then I could guess no timestamps are stored in a control header or something. I just know there's picture layer in this h263 and that's it. How are those timestamps defined/created?
[14:44] <JEEB> you have a video stream in a container, the container contains the timestamps
[14:44] <JEEB> the video stream itself doesn't have to have them, and mostly even if you have them they will not help you much (esp. with variable rate content such as from mobile devices)
[14:47] <chele> The thing is I recieve from the peer two streams. In the audio stream I have such info in the header (AMR). How do I get the video stream ctrl info to build a 3gp file? Could I build it knowing bitrate and framerate (e.g. extracting it from the original 3gp)
[14:48] <chele> In such case I'd have the peer manipulated. How do you apply that in a real case where you have the mobile device on the other side.
[14:49] <JEEB> if you have a 3gp container coming in from a real mobile device, don't you dare to extract that bit stream without also transferring the container's timestamps somewhere
[14:49] <JEEB> (PTS)
[14:50] <JEEB> audio is simple, at least in most cases. You just have a sampling rate and so forth, and no real problems there
[14:51] <zap0> audio problems:  endianess, bit depth, rate.
[14:52] <JEEB> yes, but that's mostly related to raw audio, this is an encoded bit stream
[14:52] <JEEB> endianness only matters after you decode it, bit depth is undefined with lossy formats (decoded to float by default in lavc in most cases) and rate is set in the bit stream
[14:54] <JEEB> the only problematic case I've seen with audio so far is FLV and audio just not being there for a while (I think that's how it went), that's a case where you really derp with simple handling of audio
[16:03] <chele> I am trying to map the metadata of two files with: ./ffmpeg -i input.3gp -map_metadata g -y ouput.3gp. What am I doing wrong?
[16:04] <chele> The error I get is this: Encoder (codec none) not found for output stream #0:1
[16:04] <chele> which is the audio stream, amrnb
[22:19] <ilyak> hiya
[22:19] <ilyak> Suppose I have a mono .wav file. How do I turn it into a same .wav file but stereo?
[22:19] <ilyak> In context of unix
[22:19] <ilyak> And I have to do that because lame can't
[22:20] <ilyak> I've tried sox -c 2 -D
[22:21] <ilyak> And it seems to alter contents for some bizzare reasons still
[22:37] <ilyak> Anybody home? I think I no longer understand how lame and mp3 work
[22:38] <burek> ilyak, try pan filter?
[22:39] <burek> http://www.ffmpeg.org/ffmpeg-all.html#pan
[22:39] <burek> pan="stereo:c0=c0:c1=c0"
[22:40] <ilyak> the problem is, my distro's ffmpeg package seems to be broken so I'm going without ffmpeg at the moment
[22:41] <ilyak> ffmpeg can also encode stereo mp3 from mono input using libmp3lame
[22:42] <ilyak> but my current concern is this: why do forced stereo MS mp3 files compress better than the mono mp3 files?
[22:42] <ilyak> From the same source but stereo/mono
[22:42] <ilyak> that they compress better (with zip) means they have less enthropy, less data
[22:43] <ilyak> (and for some reason files turned to stereo with sox compress waaaay better)
[22:43] <ilyak> I know this all sounds like crazy talk because I don't even understand what am I doing
[22:46] <ilyak> What does sox do to a .wav file so that it becomes much more compressible, on any bitrate?
[00:00] --- Fri Nov 29 2013