I have a flac file and I have to do some analysis on the waveform looking for a particular sample. So I decompressed them in PCM data, but then I need to know, where is that particular sample in the flac file.
So: I know the byte offset in the PCM data, or in a wav file, and I want to know the byte offset of the compressed sample in the flac file.
How can I do?
You can probably trace the sample back to the frame in the FLAC file. Within that frame would be more difficult if you consider the audio may have multiple channels and is generally compressed. If you look at the flac spec, I think it should be pretty easy to parse the file yourself:
http://flac.sourceforge.net/format.html
And you probably have to decode each frame in order to know what the frame length is...
Related
Why is it written in the standard that PCM in mp4 is not supported, but Sony cameras (for example A7s) somehow know how to do it. Does it violate the standard?How did they manage to do it?
MP4 is a variation of the MOV container, which itself can have PCM audio specified in the metadata. For example when processing MP4 bytes I will reference the MOV specifications.
(1) It's possible that your MP4 is really just a MOV file renamed as a .mp4.
(2) If the playing side knows to expect PCM (eg: Don't assume the incoming numbers are AAC data) then its no problem with using PCM in the MP4 container. You could safely replace all AAC bytes with PCM bytes.
(3) It doesn't break the standard as far as MOV is concerned, but MPEG decoders usually only want to see MPEG codecs (h.264 / h.265 / MP3 / AAC) in an MPEG-4 file. Some will accept such a PCM containing file, some may refuse to play it. PS: Some coders are even putting VP8/VP9 video codec inside MP4 these days.
This question and answer cover how to get the framecount and keyframe count from an AVI file, which is very useful. I've got a raw AVI file and want to count the number of keyframes (equivalent to non-dropped frames for raw AVI), but it takes a long time to process through a raw AVI file.
There is some way to get this information without fully processing the file, as VirtualDub provides both framecount and key framecount in the file information, as well as total keyframe size, almost instantly for a 25-second raw 1920x1080 AVI. But ffprobe requires count_frames to populate nb_read_frames, which takes some good processing time.
I can do some math with the file's size and the frame's width/height/format to get a fairly good estimate of the number of frames, but I'm worried the overhead of the container could be enough to throw the math off for very short clips. (For my 25 second clip, I get 1286.12 frames, when there are really 1286.)
Any thoughts on if there is a way to get this information programatically with ffprobe or ffmpeg without processing the whole file? Or with another API on windows?
I have some files encoded using the H.264 codec.
There is a loss of quality when I convert them from H.264 to H.265.
I imagine I should convert them back to raw/original file format, then encode them into H.265.
Is it possible to decompress/decode H.264 into the original format (perhaps using FFMpeg)?
Is it the best way to convert from H.264 to H.265 without quality loss?
Thank you again for your help,
H.264 is lossy; the quality is lost at encoding time. There is no way to reconstruct the original from encoded form. In contrast, decoding is lossless - it produces exactly all of the information present in H.264 file, no more, no less. If your video editing software is not horrible, your H.264->H.265 conversion is the highest quality you can theoretically achieve given the compression settings you provide (without finding your original uncompressed file); there is no benefit in a separate decoding step, as that is what your software needs to do anyway.
Imagine a bad photocopy: there is no unphotocopier that can give you the original. That's what is happening with lossy compression.
I have a bunch of .png frames and a .mp3 audio file which I would like to convert into a video. Unfortunately, the frames do not correspond to a constant frame rate. For instance, one frame may need to be displayed for 1 second, whereas another may need to be displayed for 3 seconds.
Is there any open-source software (something like ffmpeg) which would help me accomplish this? Any feedback would be greatly appreciated.
Many thanks!
This is not an elegant solution, but it will do the trick: duplicate frames as necessary so that you end up with some resulting (fairly high) constant framerate, 30 or 60 fps (or higher if you need higher time resolution). You simply change which frame is duplicated at the closest new frame to the exact timestamp you want. Frames which are exact duplicates will be encoded to a tiny size (a few bytes) with any decent codec, so this is fairly compact. Then just encode with ffmpeg as usual.
If you have a whole lot of these and need to do it the "right" way: you can indicate the timing either in the container (such as mp4, mkv, etc) or in the codec. For example in an H.264 stream you will have to insert SEI messages of type pic_timing to specify the timing of each frame. Alternately you will have to write your own muxer relying on a container library such as Matroska (mkv) or GPAC (mp4) to indicate the timing in the container. Note that not all codecs/containers support arbitrarily variable frame rate. Only a few codecs support timing in the codec. Also, if timing is specified in both container and codec, the container timing is used (but if you are muxing a stream into a container, the muxer should pick up the individual frame timestamps from the codec).
I don't know much about multimedia knowledge. I know sony .mts file is a type of H.264 container. I use ffmpeg to dump my .mts file into a .mpeg file. Except the .mpeg file is shrunk around 5 times smaller in size than .mts, the ffmpeg dump information on both files is identical. I am confusing why .mts files have large size. What important features are lost by my conversion?
Thanks!
Kejia
Thanks to all answers.
I checked the output of both again and found that there is one different place: bitrate. Then I definitely lost quality. Now I adjust the bit rate in terms of the expectation to displaying equipment---yes, considering displaying equipments is necessary (an expert's advice): $ ffmpeg -b 9498k -i my.mts my.mpg. Another interesting option is -ab, audio bit rate.
MTS files typically come from high-definition camcorders. They use the AVCHD coded which uses MPEG-4 AVC/H.264 video encoding and Dolby AC-3 (Dolby Digital) or uncompressed linear PCM audio coding. Are you sure that you are not decreasing the quality or resolution?
Your file has H.264/MPEG-4 AVC video compression and Dolby Digital (AC-3) audio compression or uncompressed LPCM audio, so this equals to a fairly large source file size.
When you export (convert) to MPG, you most likely perform a lossy compression. Please double check, especially the audio track.