Re: [FFmpeg-user] VOB files convertion failed
that is weird, if I recall correctly. 5. Depending on your goals, I'm not sure if FFmpeg is what you want to use to convert this DVD into a more user-friendly MKV or MP4 file. I might suggest HandBrake with the GUI interface, I suspect it may do what you want. FFmpeg is utterly impressive, it can do a huge array of things, but the HandBrake GUI application will find the names for the "titles" on the DVD (the feature film, the making of featurette, the deleted scenes), it will ignore vts_01_0.vob if it needs to but keep it if it should, stuff like that. You can select "MP4" from the drop-down menu and then it will tell you "I can't put AC-3 audio in an MP4 container, please use a MKV container or I might I suggest transcoding to AAC". It's not as awesome as FFmpeg, but given the VOB files you have and the MKV or MP4 you want to make, HandBrake can probably do it much less painfully. Good luck, Zak ___ 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] VOB files convertion failed
On 2018-05-09 at 1:53 AM EDT, Jamenson Ferreira Espindula de Almeida Melo wrote: Hi, Micael Silva. I tried the command you sugested. The command was: ffmpeg -analyzeduration 500M -probesize 500M -fflags +genpts -i "concat:../vob/vts_01_0.vob|../vob/vts_01_1.vob|../vob/vts_01_2.vob|../vob/vts_01_3.vob|../vob/vts_01_4.vob|../vob/vts_02_0.vob|../vob/vts_02_1.vob|../vob/vts_03_1.vob|../vob/vts_04_1.vob|../vob/vts_05_1.vob" -map 0:1 -map 0:2? -map 0:3? -map 0:4? -map 0:5? -metadata:s:a:0 language=eng -metadata:s:a:0 title="English stereo" -metadata:s:a:1 language=por -metadata:s:a:1 title="Português estéreo" -metadata:s:s:0 language=eng -metadata:s:s:0 title="English" -metadata:s:s:1 language=por -metadata:s:s:1 title="Português" -codec:v copy -codec:a copy -codec:s copy -f vob crepusculo.mp4 Okay, a few major tips or points: 1. I recommend HandBrake, at least to turn many VOB files into one manageable file (an MP4 or MKV, perhaps). 2. I have not used MPlayer, but Micael Silva recommended it and I have heard it is good. HandBrake is a GUI and MPlayer is a command line utility. (However, HandBrake can be accessed from the command line, and there are GUI front-ends for MPlayer.) 3. I suspect HandBrake or MPlayer will solve most of your problems. 4. You cannot use the concat filter on VOB files from different title sets, see my prior email. vts_01_1.vob is from the title set 01. vts_02_1.vob is from the title set 02, and it will not fit in the same file as title set 01. Also, you may or may not be able to include vts_01_0.vob, it is really hard to tell without parsing the IFO file, and FFmpeg cannot do that (as far as I know). HandBrake and MPlayer can definitely do that. Without parsing the IFO file, I might just try doing concat of vts_01_1.vob (but do NOT include vts_01_0.vob), plus vts_01_2.vob, vts_01_3.vob, and vts_01_4.vob, and THAT'S ALL, you need to stop there. If the first chunk of the movie is missing, you can try again but include vts_01_0.vob. 5. In FFmpeg, you should not use MP4 as the output container. In HandBrake that will be okay, because it will give you a nice verbose warning if it won't work. In FFmpeg, use MKV. Just use MKV every time. MKV is very flexible. 6. Simplify the experimental command: Don't include the metadata about language with the 3-character ISO code, the cleartext "title" in Unicode, and all that stuff. Get the video and audio working. Why don't you just map the video stream and just one audio stream? Once that works, you can go back and add more. Question: Is this actually the movie Twilight? Or is the title a red herring? I'm just curious, I haven't seen Twilight and I don't make any judgments. Good luck, Zak ___ 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] How can I see what version of a library is linked? (e.g. libmp3lame)
Dear FFmpeg User Mailing List,
The versions of certain libraries are printed in the banner, such as
libavcodec.
I am curious how to find information about linked libraries, such as
libmp3lame, the LAME MP3 encoder. I would like to know:
1. Was it statically or dynamically linked?
2. If dynamically linked, where is the libmp3lame.so file?
(I think the answer is /usr/local/libmp3lame.dylib in my case on my Mac,
but I want FFmpeg to tell me. I am not on Kubuntu right now, but I can
probably find it on Kubuntu also, and I'm guessing it is an .so and not
a .dylib file on that OS.)
3. What is the version of the linked library? Here is how I can ask LAME
itself, from the LAME CLI front-end for libmp3lame:
bash$ lame --version
LAME 64bits version 3.100 (http://lame.sf.net)
-
Here is my best guess:
bash$ ffmpeg -h encoder=libmp3lame
Encoder libmp3lame [libmp3lame MP3 (MPEG audio layer 3)]:
General capabilities: delay small
Threading capabilities: none
Supported sample rates: 44100 48000 32000 22050 24000 16000 11025
12000 8000
Supported sample formats: s32p fltp s16p
Supported channel layouts: mono stereo
libmp3lame encoder AVOptions:
-reservoir E...A... use bit reservoir (default true)
-joint_stereo E...A... use joint stereo (default true)
-abr E...A... use ABR (default false)
This looks promising, but it turns out all of that information is
hardcoded in this file:
ffmpeg/libavcodec/libmp3lame.c
You can even change this string:
AVCodec ff_libmp3lame_encoder = {
// ...snip...
.long_name = "libmp3lame MP3 (MPEG audio layer 3)"
...and the FFmpeg help will display whatever you type. It is not pulling
it from the library.
This is intended to be a general question, so I am not going to include
a specific FFmpeg banner because I use FFmpeg on two operating systems
(MacOS 10.12 and Kubuntu) and I have multiple versions of FFmpeg.
Thank you,
Zak F.
___
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] why ffplay cannot decode a sequence that can be decoded by ffmpeg
On 2018-06-11 at 5:32 PM EDT, Carl Eugen Hoyos wrote: 2018-06-07 23:40 GMT+02:00, mohammed bey ahmed khernache : My purpose is to calculate some metrics such as: fps, miss rate, etc, of video decoding. So I need only to decode a video without displaying it. Sorry for missing this: In this case, ffplay is the wrong tool for you, ffmpeg -i input -an -f null - may be a better idea. Okay, I am going to ask the questions that have been on my mind for this entire thread: 1. What is the goal of the original email? Frames per second is available from ffprobe, right? Does "miss rate" refer to cache misses while operating on the compressed video data? Won't the number of cache misses depend on many factors, possibly including whether the computer hardware is also busy rendering and displaying a video on the screen, such that disabling all video display actually will change the "miss rate"? This does not seem like a characteristic of the video file itself, it seems like a statistic that is only available during a specific instance of playing the video with specific software and hardware. Or maybe I am misunderstanding. The number of cache misses may in practice be exactly the same every time you play a given video on certain hardware, but the original email says the test is being run remotely on a computer that cannot display video, so any actual playback will occur on a different computer that will have different performance, unless I am misunderstanding. 2. What does ffmpeg with -f null really do, and how is it different than ffprobe? Thank you, Zak ___ 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] How can I see what version of a library is linked? (e.g. libmp3lame)
On 2018-06-12 at 4:11 AM EDT, Carl Eugen Hoyos wrote: 2018-06-12 4:42 GMT+02:00, Zak : These two questions cannot be answered by ffmpeg, by any executable, I suspect security considerations are among the reasons why this is impossible. Iirc, ldd does not work on osx, "otool -L ffmpeg" will tell you. Version information (that may not be available for all external libs but certainly for some) is a missing feature. Carl Eugen Yes, the following works on MacOS: bash$ otool -L /path/to/ffmpeg /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) # ...snip... By default, it follows symlinks all the way to a real file, and it prints the compatibility version and current version, which is nice. I can't figure out how to see what the executable actually requires, in the case where it was given a newer version than it requires. So it loads libz.1.dylib verson 1.2.5, but what version does FFmpeg really NEED? Is 1.0.0 good enough? Or does FFmpeg need >= 1.1.0? Or >= 1.2.0? Does the FFmpeg executable actually include such specific information, or will it fail if and when it looks up a symbol and can't find it? I have this question about otool on MacOS and also ldd on Linux. Sad note: libmp3lame is not dynamically linked by FFmpeg on either my Mac or my Kubuntu box. It must be statically linked, which means the version information is lost - unless I disassemble ffmpeg or something. On Kubuntu, the default behavior of GNU ld should be to use the dynamic link version if possible (I think), and it is possible to dynamically link libmp3lame.so. I may try recompiling FFmpeg and looking for the linker call with something like -lmp3lame or -llibmp3lame, and see if it is preceded by an instruction to statically link it. It looks like Danny Mitchell's compiled version of ffmpeg also has libmp3lame statically linked, or else it doesn't have it at all. And Danny Mitchell's ldd ffmpeg output lists a large number of dynamically linked libraries that I didn't enable or link in any way, so I'm guessing the MP3 encoder was not disabled. But maybe it was disabled. My ffmpeg only has one MP3 encoder (libmp3lame), although it seems to have possibly up to six decoders (I don't know whether to count MP3onMP4, for instance). I am unaware of any MP3 encoder aside from libmp3lame that is supported by FFmpeg, and I don't see any on that ldd output from Danny Mitchell. It would be nice for FFmpeg to record the versions of statically linked libraries, but it looks like it would be hard. Zak ___ 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] Question regarding encoding a file
what you want to achieve eventually, it seems to be related to the metadata inside the MP3 files. I do not recommend using foobar2000 to analyze the metadata inside the MP3 files. If your goal is to get certain metadata to appear specifically inside foobar2000, that is okay. But you need to be able to analyze the metadata with a more predictable and robust tool, such as Mutagen or eyeD3, because otherwise it will be 100 times harder to figure out where foobar2000 is reading data from. Where did "Lavf" come from in the screenshot above? I gave at least four possibilities, and I can think of more. Using eyeD3, you can manually set each of them to a different thing and then see what foobar2000 says. Then, you will see where it is reading from. Beware: foobar2000 will probably read from different places based on whether there is an ID3v1 tag, an ID3v2 tag, a LAME Info Tag (or not), and whether it can find something "good looking" when it searches the header of the MP3 file for ASCII strings. All that said, foobar2000 is an impressive and influential music player. It had the "up next" feature working, and working well, before any other music player that I am aware of, and foobar2000 had "up next" a full ten years before Apple iTunes added it. iTunes has an enormous budget, and people love this feature, so that is impressive. Although foobar2000 itself is proprietary and closed-source, the SDK works well and it gave rise to a vibrant ecosystem of plugins, and this sparked innovation and allowed community-driven invention and refinement of new features in a way that was not possible for iTunes and simply was not happening on the media players that actually were Free Software. I think this tide has shifted in the past 5 or 10 years such that the innovation is now taking place in purely Free Software media players such as Quod Libet, which has a Python API and can also send and receive messages via text files on the hard drive, which is hilarious but also extremely portable and powerful. Nonetheless, there was a period of multiple years where the boom of music player innovation was happening around foobar2000. You might really like Quod Libet, by the way. foobar2000 has not gotten significant new code in a long time. In that time, many of the Free Software media players have gotten a lot better. Zak ___ 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] How to enforce VBR minimum bitrate
fp,1); Will I crash my computer for the second time in one day? Let's see. Zak ___ 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] How to enforce VBR minimum bitrate
respect the minimum frame size. In VBR mode, FFmpeg wants to make 32 kbps frames if it feels like they are high-enough quality. Working solution, use two steps: Step 1: bash$ ffmpeg -i foo -args -args -more_args intermediate.wav Step 2: bash$ lame -V 5 -F -b 128 intermediate.wav output.mp3 bash$ rm intermediate.wav The commands above will work assuming the FFmpeg command in step 1 works and assuming you have a semi-recent version of LAME. I recommend the latest version of LAME, they don't come out very often and they get progressively better. Alternative solution, not as good: Use an ABR mode. This will give worse audio quality, and you may still get frames smaller than 128 kbps, especially if you set the ABR target as 135 kbps, which is the midpoint of 120-150 kbps. Let's try it: Oh, I actually can't get this to work. The solution likely looks like this, kind of: bash$ ffmpeg -i song.wav -codec:a libmp3lame -abr:a -b:a 135k output.mp3 The above does not work for me, I tried a few variations and it is not valid syntax, but I don't recommend ABR for MP3 in general, and it also probably won't solve this problem because if the target is 135 kbps, then 32 kbps frames are very likely to show up in the output. There just won't be as many as -V 5. ABR at 135 kbps will likely have a huge number of 112 kbps frames, which is already below your desired minimum. Note that the LAME docs imply that -F only applies to frames of silence. This is only implied, the term "silence" is not defined rigorously, and in reality you need the -F option if you are trying to make the MP3 play on a device or in software that can't handle small frames. Devices or software that need a minimum frame size really NEED a minimum frame size, even for silence. ABR might be a viable option if your goal is to make sure the total audio size is predictable, or above some minimum. ABR will not give good results in terms of audio quality, and it will use 32 kbps frames sometimes (possibly breaking your player), but it will ensure a minimum size for the finished audio file. If you use ABR with a target of 150 kbps, then I think it is unlikely the finished product will average less than 128 kbps. ABR doesn't promise to come within any margin of the target, but it comes very close usually. Good luck, Zak F. ___ 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] mpegts metadata not set
On 2018-06-27 at 10:28 AM EDT, Christian Knoefel | Ilm-Provider wrote: Hello, i will remux an ts: ffmpeg -re -i rtmp://live.net/rtmp/live -vcodec mpeg2video -s 720x576 -r 25 -flags cgop+ilme -sc_threshold 10 -b:v 5M -minrate:v 5M -maxrate:v 5M -bufsize:v 3.5M -acodec mp2 -ac 2 -b:a 192k -metadata "service_provider=Some Provider" -metadata "service_name=Some Channel Name" -f rtp_mpegts rtp://127.0.0.1:5000?pkt_size=1316 Stream mapping: Stream #0:1 -> #0:0 (h264 (native) -> mpeg2video (native)) Stream #0:0 -> #0:1 (aac (native) -> mp2 (native)) Press [q] to stop, [?] for help Output #0, rtp_mpegts, to 'rtp://127.0.0.1:5000?pkt_size=1316': Metadata: service_provider: Some Provider service_name : Some Channel Name encoder : Lavf58.17.100 Stream #0:0: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 5000 kb/s, 25 fps, 90k tbn, 25 tbc Metadata: encoder : Lavc58.20.103 mpeg2video Side data: cpb: bitrate max/min/avg: 500/500/500 buffer size: 350 vbv_delay: -1 Stream #0:1: Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s Metadata: encoder : Lavc58.20.103 mp2 wit ffplay looks like this: Input #0, rtp, from 'rtp://127.0.0.1:5000': 0KB sq= 0B f=0/0 Duration: N/A, start: 91.443144, bitrate: 5192 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:1: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bottom first), 720x576 [SAR 64:45 DAR 16:9], 5000 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:0: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 192 kb/s Why metadate are not set? it is the newest 64bit windows build... thanks for your suggestion... Christian Hello Christian, I suspect the root problem is this: 1. When FFmpeg (the first call, for transcoding/remuxing), when FFmpeg creates the MPEG TS, where is it putting the "metadata"? The MPEG transport stream protocol is SUPER old, I would be surprised if there were less than a dozen ways to store metadata. 2. When FFplay tries to play back the MPEG TS stream, where is it reading the metadata? Quite likely not the same place. I have no idea. Here are some suggestions: 1. Consider what application you actually want to use for playback, because they will support different types of metadata. VLC, for example, supports VERY LITTLE metadata, which annoys me at times. Even if VLC reads the format for the metadata, it will never show you certain keys, it only shows you a few of the keys. For instance, "Get Info" on VLC usually shows a key "Year" for streaming video, but I know the video has "original air date" (year, month, and day), "copyright date", and possibly other things. And then "Year" is "2018", and that's just not right. That was the encoding year, probably. FFprobe can actually be helpful determining what is going on with things like this if you have no idea (because I have no idea how metadata is stored in MPEG transport streams). 2. MAYBE try putting the -metadata arguments after the "-f rtp_mpegts" argument. Sometimes (often) the order of arguments matters in FFmpeg. I have no idea if that is the case here. Maybe it "processed" -metadata early, when it thought you were going to use a MKV file as the output, and it got that metadata all ready for a MKV file. Then it saw "-f rtp_mpegts" and it threw away the things that go in MKV but not in MPEG TS, and then re-generated some metadata for MPEG TS. This is a wild guess, I would try it. The order of arguments mostly matters when the arguments apply to specific streams (like audio versus video versus the audio commentary). You can specify streams with (colon)(digit), such as -c:v:2, but some arguments do not support that syntax (as far as I know), so you need to put the argument in the group with that whole stream, and the location tells it to go with "2". 3. Before somebody else asks, you might want to include the whole uncut console output, including the "banner" printed by FFmpeg and FFplay that says the configuration options when it was compiled, and so on. I suspect it is not going to be hugely relevant, but you never know. You did say it is the latest Windows build, but these Mailman archives will be around for a long time, and what if you think you are using the latest build because you installed it, but at the hour of typing the command, your PATH variable decided to use an older version of FFmpeg that was lying around somewhere on your hard drive? (There is a nice xkcd comic about having tons of versions of the Python interpreter on one machine, because computers get messy.) Good luck, Zak ___ ffm
[FFmpeg-user] Sample types 's32 (24 bit)' and 's16 (24 bit)' are confusing to me
Dear FFmpeg Community, I have seen two sample types (similar to the output of -sample_fmts but maybe different) that confuse me because they are unclear about the bit depth of the samples involved. The two strange sample types are: s32 (24 bit) s16 (24 bit) Those are verbatim strings. I have seen both of them, I am copy-pasting them from my log files. I can see these either on calls to ffprobe or on calls to ffmpeg. Here is an ffprobe call that always reproduces the behavior: bash> ffprobe "01 - Let It Go.flac" ffprobe version 3.0.2 Copyright (c) 2007-2016 the FFmpeg developers built with llvm-gcc 4.2.1 (LLVM build 2336.11.00) configuration: --prefix=/Volumes/Ramdisk/sw --enable-gpl --enable-pthreads --enable-version3 --enable-libspeex --enable-libvpx --disable-decoder=libvpx --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-avfilter --enable-libopencore_amrwb --enable-libopencore_amrnb --enable-filters --enable-libgsm --enable-libvidstab --enable-libx265 --disable-doc --arch=x86_64 --enable-runtime-cpudetect libavutil 55. 17.103 / 55. 17.103 libavcodec 57. 24.102 / 57. 24.102 libavformat 57. 25.100 / 57. 25.100 libavdevice 57. 0.101 / 57. 0.101 libavfilter 6. 31.100 / 6. 31.100 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.101 / 2. 0.101 libpostproc 54. 0.100 / 54. 0.100 Input #0, flac, from '01 - Let It Go.flac': Metadata: ALBUM : Megahits 2013 ARTIST : Idina Menzel COMMENT : Vinyl rip by Radioactive Squirrel DATE : 2013 TITLE : Let It Go TRACKTOTAL : 18 track : 1 Duration: 00:03:48.29, start: 0.00, bitrate: 2701 kb/s Stream #0:0: Audio: flac, 96000 Hz, stereo, s32 (24 bit) There it is, at the bottom of the ffprobe output, "s32 (24 bit)". Here is how you reproduce it from ffmpeg, but this is not actually copy-pasted: bash> ffmpeg -i "01 - Let It Go.flac" output.wav # In the first chunk of printed output, about the input FLAC: Stream #0:0: Audio: flac, 96000 Hz, stereo, s32 (24 bit) # In the second chunk of printed output, about the WAV it is generating: Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 96000 Hz, stereo, s16 (24 bit), 3072 kb/s I am fairly certain the input FLAC is 24-bit (i.e. 24 bits per sample), and I am 99.9% certain the output WAV is 16-bit. Why does the FLAC say "s32", which refers to a signed 32-bit integer? Why does the WAV say "(24 bit)", which is simply not true? Notice that I didn't actually supply a -sample_fmt argument to the ffmpeg call above. By default it chooses pcm_s16le and "s16 (24 bit)". I am not sure what happens if I call ffmpeg -i input.flac -sample_fmt s16 output.wav but I could test that. Thank you for any words of wisdom, Zak ___ 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] Why H264 Encoder is slower than H265 Encoder?
Hello Shi Qiu, I have two thoughts: 1. Is that the best possible experiment with only one variable changed between the two cases? It looks like the input format changed, too, although the filenames are possibly fake simple examples (simplicity is good). The H264 output has a.h264 as the input and the H265 output has a.h265 as the input file. Even if the contents should be the same, for instance if they are the same short film, the a.h265 file may be significantly easier to compress for some reason. I would do the experiment with a totally different video format, maybe VP9, and use the exact same input file for both output formats. 2. Algorithms that have seen more development attention in the recent past are often faster than older algorithms, even if in theory the older algorithm should be simpler to implement. This is because recent attention often means optimizations. In the case of H.265, I'm not sure, but aren't there special CPU instructions on recent Intel processors? There are other ways to optimize code if you have time and money. A good example that you can see in ffmpeg is the LAME library (libmp3lame) compressing 320 kbps CBR (constant bitrate) versus V0 VBR (variable bitrate) MP3 outputs. 320 kbps CBR and V0 VBR are the highest-quality CBR and VBR formats, respectively. The CBR algorithm is older. The VBR algorithm is newer, has seen more recent development attention, and is about 5 times faster in my tests on MacOS 10.12 and Kubuntu 17.04. Here are the tests I used: # Output 320 kbps CBR: ffmpeg -i Exact_same_song.flac -codec:a libmp3lame -b:a 320k -map_metadata 0 output.mp3 # Output V0 VBR, about 260 kbps average depending on input: ffmpeg -i Exact_same_song.flac -codec:a libmp3lame -q:a 0 -map_metadata 0 output.mp3 You get the same result if you use the LAME CLI directly, but you need to make a WAV file for input first (perhaps with ffmpeg): # Output 320 kbps CBR: lame -b 320 -q 0 -T --id3v2-only --tt "Song" input.wav output.mp3 # Output V0 VBR: lame -V0 -q 0 -T --id3v2-only --tt "Song" input.wav output.mp3 I included metadata in both cases, ffmpeg and LAME CLI, because if an ID3 tag is not needed then it will not write the Xing (VBR) or Info (CBR) header in the MP3. Inspecting this header, it is not entirely clear, but it looks like ffmpeg does not use -q 0. ffmpeg probably used -q 3, which is the default, and this may explain why ffmpeg was faster. -q 0 tells the encoder to use the highest-quality and slowest algorithms. In both cases, VBR (the newer but more complex algorithm) is about five times faster than CBR (the older and simpler algorithm). If anyone is curious, 320 kbps output gets a little faster every single time you decrease the quality (-q 0 is 14 minutes encoding time for a 1-hour sound file, -q 1 is 7 minutes (twice as fast), -q 2 is 6 minutes, -q 3 is 3.5 minutes, and so on), but VBR output only gets faster when you pass certain values of -q n. To be specific, -q 0, -q 1, and -q 3 seem to be totally identical, and -q 7, -q 8, and -q 9 are also identical, it seems. Even at -q 0, VBR is extremely fast compared to CBR, and it only gets faster as you turn down the quality. Regards, Zak On 2/7/18 8:41 PM, Shi Qiu wrote: OS: Ubuntu 16.04 64bit CPU: intel i7 6700 H264: ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device /dev/dri/renderD128 -i a.h264 -c:v h264_vaapi -f h264 t.h264 -y 108fps H265: ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device /dev/dri/renderD128 -i a.h265 -c:v hevc_vaapi -f hevc t.h265 -y 126fps Any ideas? ___ 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] Why _COPYing_ a variable encoded audio (AAC) channel will produce a variably encoded one?
Hello Sophoklis, Short version: I strongly suspect the audio data was copied directly and simply. I strongly suspect it is bit-for-bit identical audio data, it was not decompressed and recompressed with different settings. Advice for you: I am not sure this is the case, we will have more evidence if you can give the full FFmpeg printed output, including STDOUT and STDERR. Just issue the command and copy-paste everything out of the terminal emulator. I also recommend running ffprobe on the input and the output and pasting that data too, so you will do a total of three commands. Disclaimer: I know absolutely nothing about the 3GP container file format. I do know a fair amount about audio compression algorithms, including AAC. I have several pieces of evidence that FFmpeg did not modify the audio data: 1. The original metadata is suspicious based on my knowledge of AAC. It says the "Bit rate" is "32.0 kb/s" for the original, but it is not clear which aspect it is referring to. Is that the average bitrate calculated by actually counting bytes and dividing by the duration in seconds? Or is that the average bitrate based on reading some metadata in the 3GP file and trusting it on faith? I suspect the latter is more likely. It may even be a target given to the AAC encoder, and the user-specified target bitrate is different than the final bitrate that was actually achieved depending on the audio content and the other settings given to the encoder. 1.B. The other extremely suspicious thing is that "Bit rate" (unclear meaning) is 32.0 kb/s, but "Maximum bit rate" (clear meaning, but may not be accurate) is 34.4 kb/s, which is only 7.5% larger. Now, the AAC codec allows you to specify entirely arbitrary bitrates, so it is possible to ask for variable bitrate (VBR), target of 32 kb/s, and maximum of 34.4 kb/s. That is a very weird thing to ask for, and you would need to supply an argument for the maximum bitrate (unless the audio signal is very weird). You can ask for that, but I doubt anyone asked for that. A much more common thing to ask for is variable bitrate (VBR), target of 256 kb/s, and maximum of 320 kb/s. Note that 320 is a full 25% larger than 256, which allows the encoder to actually take advantage of the VBR benefits. If you only give it 7.5% to work with, you might as well ask for constant bitrate (CBR), which I suspect is what they actually did. 1.C. The frame rate and samples per frame are identical in the input and the output. 1.D. The size of the audio data is identical in the input and the output. 2. I think all of the data that appears different for the two formats, 3GP and M4A, is almost certainly due to how the metadata is stored in those two different container types and where FFmpeg reads the data from. I know absolutely nothing about 3GP, but it is quite possible that it stores some of that data in the file, and FFmpeg is just reading it and displaying it, even if it is incorrect. I do know a fair about about M4A, the spec for how to store metadata is not standardized at all, and it is entirely possible to store a bitrate that is just not true. Many pieces of software will read it, display it, and it just isn't the bitrate of the audio. What you really want is a software tool that can count the number of bytes of audio data, and calculate the duration in seconds (not read it from metadata, actually decode the audio and measure how long it is), and then give you the actual bitrate. I don't know any software that does this for M4A and AAC, sadly. A piece of software that does this for MP3 is Mutagen (Python library). I suspect MediaInfo may be able to do this for M4A containers and AAC data. MediaInfo can probably also handle the 3GP container. If you give me an MP3 file or an Ogg Vorbis file, I can "fool" FFmpeg into saying that it is a very wrong bitrate and duration. The forged file will probably play in VLC, but there are many pieces of software that probably would give errors. I don't know M4A as well, but M4A is even more haphazard, so it is probably very easy to mess up the bitrate and duration data, especially by accident. MP3 files rarely have this type of error by accident, except maybe a 2-second error if the MP3 was ripped from a CD with a 2-second pregap. I have seen this cause media players to skip to the next song 2 seconds before the current song actually ended. iTunes and VLC will not be fooled, but many things will mess up. Zak On 2/28/18 7:40 AM, Sophoklis Goumas wrote: Hello. I have a .3gp file containing a video and an audio channel. I'm trying to get the audio channel in a separate m4a file but when I issue: ffmpeg -i foo.3gp -vn -c:a copy foo.m4a I get a constantly encoded AAC audio channel while the original was a variably encoded one. In more detail, from this: Format: AAC Format/Info : Advanced Audio Codec Format p
Re: [FFmpeg-user] ffprobe audio duration mismatch
On 3/20/18 9:10 PM, Carl Eugen Hoyos wrote: 2018-03-21 1:56 GMT+01:00, Zak <ffmpeg-user-em...@m.allo.ws>: What you ideally want is a software library that can decode the audio data itself and deduce the duration. What's wrong with FFmpeg? Please do not top-post here, Carl Eugen Wait, what does "please do not top-post" mean in your opinion? My email didn't include a quote at all. This is a bottom-post so I don't think it is a top-post. Isn't not quoting at all orthogonal to either top-posting or bottom-posting? I'm not trying to be difficult, I am honestly confused why two people have been reprimanded for a reason that I do not understand in this thread thus far. Obviously omitting the original message isn't bad, because you omitted most of the message I just posted, and I fully support that decision. You quoted the part that you replied to. There is nothing wrong with FFmpeg, but at least for MP3 files, I do not know how to easily get it to report the actual number of frames or actual duration of the MP3 data stream with all the precision that is possible and without relying on the metadata that might be wrong. If I do "ffprobe song.mp3", it rounds the duration to 0.01 seconds, it rounds the bitrate to 1 kb/s, and it seems to be reporting some information from the LAME Info Tag, which could theoretically be wrong (but usually it is not, the LAME Info Tag has a CRC checksum and it is rarely touched by batch tag editors). For instance, the replaygain data definitely comes from the LAME Info Tag. The original question seemed interested in very high precision. FFmpeg doesn't report this information with the most possible precision, and that's fine in most contexts, and FFmpeg also doesn't say exactly where the information came from, which is also fine. There are software libraries that do these things, if you really want them. Zak ___ 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".
