Re: [FFmpeg-user] rotation question
On Thu, 09 Jun 2016 18:23:14 -0600, jd1008 wrote: >I need to rotate a video 180 degrees horizontally; i.e. what is left >should be right and vice versa. >How can I achieve that? Perhaps, -vf hflip ___ >ffmpeg-user mailing list >ffmpeg-user@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-user > >To unsubscribe, visit link above, or email >ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg development
On Wed, 20 Apr 2016 09:25:23 +0200, Moritz Barsnick wrote: >It appears to me that Steve wanted static normalization (i.e. a >constant change of volume across the whole audio stream), not dynamic >though. > >Moritz Yes. I appreciate your distinction but if he meant for the normalisation to occur across a set of videos it might be something to consider. It does seem to bring audio peaks to about -1 dB throughout a clip while retaining a reasonable dynamic range. I didn't check what happens at saturation level of an input file. Thanks Moritz. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] ffmpeg development
On Sat, 16 Apr 2016 16:43:01 +, Steve Corrao wrote: >Explanation of Conditional Statement and Example: >1. run astats or volumedetect to calculate RMS level. >2. If RMS level = X dB, then add Y dB level to match the user specified dB >level. >Example: If RMS level = -30dB, and user specified RMS level = -20dB, > then add 10dB. >Please feel free to respond to stevecor...@outlook.com is this project anyone >is interested in developing. This seems to have some value. Tried it? ffmpeg -filters ... dynaudnormA->A Dynamic Audio Normalizer. and so ... -af dynaudnorm Seems to set peaks ~ 0 and raises lower levels by 6dB etc ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Input 5.1 DTS, output 2.0 MP3: Atrocious Quality
On Sun, 17 May 2015 02:16:56 -0500, John L wrote: >- >the resulting wav file is significantly distorted, but qualitatively doesn't >'feel' as harsh > Just FYI John, _some_ of those channels in the 5.1 are already flattening at peak levels so the sound overall, will never be great. Of course, this is not an FFMPEG thing or even related to your transcode issue. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Input 5.1 DTS, output 2.0 MP3: Atrocious Quality
On Sun, 17 May 2015 07:41:31 + (UTC), Carl Eugen Hoyos wrote: Not a problem about misunderstanding. Hope I make sense sometimes too -) > I did now and the question now is: > Is the issue reproducible with: > $ ffmpeg -i inter.dts -ac 2 -acodec pcm_f32le outf.wav This (above) produces the the same overload/over-modulation/ distortion as in the original raised issue. You were expecting it? OP seems to think its an fltp issue. >If not, what about the following? >$ lame outf.wav Sorry. This last makes no sense to me. I don't have lame installed. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Input 5.1 DTS, output 2.0 MP3: Atrocious Quality
On Sat, 16 May 2015 10:25:09 + (UTC), Carl Eugen Hoyos wrote: >Since your answer makes no sense (is ac3 doubly bad?), >maybe you could map 1, 2, 3, 4 to out.mp2, out.ac3 and >the two wav files? They say a picture is worth 1000 words etc so I'll do it this way. This is John's problem. Bad sound when 'downing' 5.1 to stereo. In his case, an attempt to use libmp3lame. Ignoring bitrates, the problem seems to boil down to whether the '-ac 2' option is being fully honoured (in channel numbers AND levels). The simple command 'ffmpeg -i inter.dts -ac 2 -ab 320k out.mp3', for an MP3 file, will produce this result. Plainly distorted. -) The links are captured PNG image files from Adobe's Audition. http://www.datafilehost.com/d/ef36d01a You asked for 4 tests to be carried out. Here they are. In order. 1). > $ ffmpeg -i inter.dts -ac 2 out16.wav Conversions to WAV types are OK and will downmix. This one did. Sounds are fine http://www.datafilehost.com/d/85290f50 2). > $ ffmpeg -i inter.dts -ac 2 -acodec pcm_s32le out32.wav Likewise for this other (32) codec. Performed as expected. http://www.datafilehost.com/d/fb55d8fe 3). > $ ffmpeg -i inter.dts -ac 2 -ab 640k out.ac3 The process FAILS in this case(s). For AC3 and AAC. For these types of outputs, Audition does not recognize the file types so, to get around the problem of display, the AC3 and AAC types were converted back into a WAV type. The channels are there. The output level is just overloaded. The resultant output is virtually identical to John's initial problem wherein (I guess) the input channels are 'unweighted' http://www.datafilehost.com/d/932be2b6 4). > $ ffmpeg -i inter.dts -ac 2 -ab 320k out.mp2 I initially thought that the MP2 was similarly irregular but now, I think I got myself confused with all the test files. This MP2 conversion appears to be OK. It too, is not importable into Audition so like (3) above, it had to be rendered to WAV. However, it seems to behave properly as expected. http://www.datafilehost.com/d/859a9402 This is as far as I can go. I'd like to believe that '-ac 2' was universal -) It is, in the sense that all channels are mixed. The volume option is a workaround. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Input 5.1 DTS, output 2.0 MP3: Atrocious Quality
On Sat, 16 May 2015 09:17:59 + (UTC), Carl Eugen Hoyos wrote: >Sorry, I am apparently extremely dim-witted: >Did you test the four lines above? >Which of them sound ok, which of them do >not sound ok? Seem to have not explicitly answered the Q. Sorry. >$ ffmpeg -i inter.dts -ac 2 out16.wav >$ ffmpeg -i inter.dts -ac 2 -acodec pcm_s32le out32.wav >$ ffmpeg -i inter.dts -ac 2 -ab 640k out.ac3 >$ ffmpeg -i inter.dts -ac 2 -ab 320k out.mp2 1 = Good 2 = Good 3 = Bad 4 = Good and 1 you didn't list, AC3 = Bad ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Input 5.1 DTS, output 2.0 MP3: Atrocious Quality
On Sat, 16 May 2015 09:17:59 + (UTC), Carl Eugen Hoyos wrote: >Bazza jeack.com.au> writes: > >> >Please test the following: >> >$ ffmpeg -i inter.dts -ac 2 out16.wav >> >$ ffmpeg -i inter.dts -ac 2 -acodec pcm_s32le out32.wav >> >$ ffmpeg -i inter.dts -ac 2 -ab 640k out.ac3 >> >$ ffmpeg -i inter.dts -ac 2 -ab 320k out.mp2 >> >> Carl, I did test some of this stuff. > >> - MP3 suffers overload >> - WAVs are OK >> - AC3 suffers overload >> - AAC are OK >> - MP2 are OK > >Sorry, I am apparently extremely dim-witted: >Did you test the four lines above? >Which of them sound ok, which of them do >not sound ok? >Thank you, Carl Eugen Tested them all Carl. It's not quite a case of "sounding OK" it's that they are patently just "wrong". I'm using a Windows /Zeranoe build. Observing results through Adobe's Audition. Results are independant of bit rate (as you specify),I tried those (and some other rates). All fail. Also, it appears to be independant of the codecs 16 Vs 32 etc. The audio signals in John's sample have 6 mono. Most of those are up to the clipping level when viewed separately. When he "combines" them (let's say via declaring -ac 2) the channels (all 6) do indeed mix but the 'numbers' are summed greater than the streams capability - hence severe clipping and overload. This appears to happen in the case of AC3 and MP3 (which is John's complaint). In doing a bit of reading, it seems to be the case that L,R, FL and FR are usually attenuated by 3dB per signal. Maybe that 'routine' is being bypassed (or not even called) in AC3 or MP3 situations. This is a pure guess but the numbers do "add up" when we drop a volume by 10 dB. Luckily his levels nearly clip. Now, I must add, Adobe's Audition does not like viewing AC3 and AAC stuff directly so I do a re-convert from the AC3 and AAC back into WAV (just to view) but, no doubts about it, does not look good. Output in the non-behaving file format is just too high a level. FFMPEG generates no complaints so that's good. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Input 5.1 DTS, output 2.0 MP3: Atrocious Quality
On Sat, 16 May 2015 07:52:12 + (UTC), Carl Eugen Hoyos wrote: >Please test the following: >$ ffmpeg -i inter.dts -ac 2 out16.wav >$ ffmpeg -i inter.dts -ac 2 -acodec pcm_s32le out32.wav >$ ffmpeg -i inter.dts -ac 2 -ab 640k out.ac3 >$ ffmpeg -i inter.dts -ac 2 -ab 320k out.mp2 Carl, I did test some of this stuff. It seemed that attempts to downmix via -ac 2 would work OK for WAV (pcm_s16le) but anytime converting to other formats (AC3, or MP3s) generated significant signal overload. However, the channel mixing DID occur. A workaround was to include -af volume=-10dB. However, although I'm not the poster with the problem, I've just done your suggestions and, for me ... - MP3 suffers overload - WAVs are OK - AC3 suffers overload - AAC are OK - MP2 are OK But I'll let him speak ... ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Input 5.1 DTS, output 2.0 MP3: Atrocious Quality
On Fri, 15 May 2015 23:04:06 -0500, John L wrote: >Backstory: I have a system in place to automagically convert video files to >smaller formats/versions on request to have a sort of "mobile version" for my >father who travels extensively. The purpose is so that he can fit >significantly more videos on his tablet than if they were the high quality >rips. > >It all boils down to: >ffmpeg -i [input-file] -ac 2 -c:v libx264 -c:a libmp3lame -b:v 1024k -preset >fast [output-file] > >I was under the impression everything was hunky dory until I took a bunch of >the shrunken movies on my phone on a roadtrip. A good many of the videos were >as good as can be expected, and nothing was egregiously wrong. However on a >few videos the audio was absolutely atrocious, blown out, clipping, and just >noise from seemingly nowhere. > >One of the worst was Intersteller which was completely unwatchable after the >first two minutes with all the blown out crescendos, pops, cracks, static, and >voices of the deep adulterating the audio stream. All video files affected by >this were 5.1DTS sources, but not all 5.1DTS were affected. > >When talking with my father he said it was a frequent enough occurrence that >he suspected it was just because I had shrunk the file so small and was an >artifact of that. He did confirm that most videos that were affected weren't >as bad as the Interstellar conversion. > > > >~/testing$ ffmpeg -version >ffmpeg version 2.5.6-0ubuntu0.15.04.1 Copyright (c) 2000-2015 the FFmpeg >developers >built with gcc 4.9.2 (Ubuntu 4.9.2-10ubuntu13) >configuration: --prefix=/usr --extra-version=0ubuntu0.15.04.1 >--build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu >--shlibdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu >--enable-gpl --enable-shared --disable-stripping --enable-avresample >--enable-avisynth --enable-ladspa --enable-libass --enable-libbluray >--enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite >--enable-libfontconfig --enable-libfreetype --enable-libfribidi >--enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame >--enable-libopenjpeg --enable-libopus --enable-libpulse >--enable-libschroedinger --enable-libshine --enable-libspeex --enable-libssh >--enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libwavpack >--enable-libwebp --enable-lib > xvid --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 > --enable-libzvbi --enable-libzmq --enable-frei0r --enable-libvpx > --enable-libx264 --enable-libsoxr --enable-gnut > ls --enable-openal --enable-libopencv --enable-librtmp --enable-libx265 >libavutil 54. 15.100 / 54. 15.100 >libavcodec 56. 13.100 / 56. 13.100 >libavformat56. 15.102 / 56. 15.102 >libavdevice56. 3.100 / 56. 3.100 >libavfilter 5. 2.103 / 5. 2.103 >libavresample 2. 1. 0 / 2. 1. 0 >libswscale 3. 1.101 / 3. 1.101 >libswresample 1. 1.100 / 1. 1.100 >libpostproc53. 3.100 / 53. 3.100 > > >To troubleshoot I copied out a particularly bad snippet of audio >ffmpeg -i Int*.mkv -vn -c copy -ss 1:30 -t 0:30 inter.dts Yes. That snippet has about 6 tracks. Some of them are clipping (all on their own). >This audio clip is confirmed to be a good 5.1dts stream Good? Well OK -) >ffmpeg -i inter.dts -ac 2 -c libmp3lame inter-test.mp3 >This audio sample has the exact same audio defects as in the shrunken video Correct. All tracks (some of which had reached maximum encodable levels) are now being added/summed into 1 single (now) overloaded stream. Instead, take the 5.1 and _DOWNMIX_ all tracks to a single stereo for the phone/tablet by declaring -acodec -ac 2. No intermediate steps should be required. Consider also - Do you need pcm_s32le ? pcm_s16le is usual. > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Output file experience pix_format change
On Fri, 30 Jan 2015 13:40:07 +1100, Bazza wrote: >I suppose my basic question is this. >Should the output be undergoing this format alteration under any >circumstances? Or, put another way, does libx264 ignore some >recognition of the pix format some of the time? If so, why? >Perhaps those color commands are forcing new 'acknowledgements' >on the 264 filter by necessity? > >It seems odd that some parameters leave the file untouched and a >little confusing when one has to remember extra behaviour patterns. >Just trying to clear up my understanding. Thank you both - Moritz and Andy. Moritz for the insight into the filter (I kinda figured that was the underlying process but needed it to be confirmed) and Andy for the Mplayer's hiccups. I suppose I should ask a supplementary question. Given that a file might switch from yuv420p to yuv444, is there any great significance to domestic equipment? I see the failure of Mplayer to cope with the change but can this failure also apply elsewhere? In a sense, should one aim for yuv420p for compatibility? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
[FFmpeg-user] Output file experience pix_format change
Just for learning fun, I have been playing with the colorbalance, colorlevels and colorchannelmixer filters as outlined here :- http://ffmpeg.org/ffmpeg-all.html#file The default viewer, to see what has happened, is Mplayer. Using _THAT_ viewer , results in a very greyed output with no discernable detail, however VLC and FFPLAY will display the resultant file quite well. At first, I thought the fault may have been in the Zeranoe build. Well it isn't. Now if I do this :- ffmpeg -y -threads auto -i File1.mp4 -vcodec libx264 -vf scale=720:576 -acodec copy outfile.mp4 ...the outputfile has a pix format of yup420p (same as it's input file). For most (all ?) of the "standard" -vf parameters and for all of the mp4 input files I used as tests, the pix_format remains at yuv420p in the resulting output. However when using colorbalance/colorlevels/colorchannelmixer, the output files has undergone a pix_format change to yuv444p and it is this which disturbs MPLAYER. Irritating though the Mplayer malfunction(?) might be, it is the _format_ change I am focussing on (and yes, I see that H264 likes a 444 default). --- As an example ... This will effect a format in the output. (Mplayer unhappy) ffmpeg -y -threads auto -i File1.mp4 -vcodec libx264 \ -vf colorlevels=rimax=0.902:gimax=0.902:bimax=0.90 -acodec copy \ outfile.mp4 --- but this restores the format(as you would expect - Mplayer happy) ffmpeg -y -threads auto -i File1.mp4 -vcodec libx264 \ -vf colorlevels=rimax=0.902:gimax=0.902:bimax=0.90 -acodec copy \ -pix_fmt yuv420p file.mp4 I suppose my basic question is this. Should the output be undergoing this format alteration under any circumstances? Or, put another way, does libx264 ignore some recognition of the pix format some of the time? If so, why? Perhaps those color commands are forcing new 'acknowledgements' on the 264 filter by necessity? It seems odd that some parameters leave the file untouched and a little confusing when one has to remember extra behaviour patterns. Just trying to clear up my understanding. Just to show it really is happening:- ffmpeg -y -threads auto -i H:\File1.mp4 -acodec copy -vcodec libx264 -vf colorlevels=romin=0.5:gomin=0.5:bomin=0.5 e:\Outfile.mp4 ffmpeg version N-69375-g4155f2d Copyright (c) 2000-2015 the FFmpeg developers built on Jan 28 2015 22:14:02 with gcc 4.9.2 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enable-zlib libavutil 54. 18.100 / 54. 18.100 libavcodec 56. 21.101 / 56. 21.101 libavformat56. 19.100 / 56. 19.100 libavdevice56. 4.100 / 56. 4.100 libavfilter 5. 9.101 / 5. 9.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc53. 3.100 / 53. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'tk.mp4': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: isommp42 creation_time : 2014-03-01 03:29:00 Duration: 00:03:49.62, start: 0.00, bitrate: 1326 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1131 kb/s, 25 fps, 25 tbr, 25 tbn, 50 tbc (default) Metadata: handler_name: VideoHandler Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 191 kb/s (default) Metadata: creation_time : 2014-03-01 03:29:01 handler_name: IsoMedia File Produced by Google, 5-11-2011 No pixel format specified, yuv444p for H.264 encoding chosen. Use -pix_fmt yuv420p for compatibility with outdated media players. [libx264 @ 04d8e9c0] using SAR=1/1 [libx264 @ 04d8e9c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX [libx264 @ 04d8e9c0] profile High 4:4:4 Predictive, level 3.1, 4:4:4 8-bit [libx264 @ 04d8e9c0] 264 - core 144 r2525 40bb568 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 b luray_compat=0 constrained_intra=0 bf
