I'm new to video compression; but I see many of the terms repeated over and over again.
I'm wondering what's the difference between x.264 and libx264 and H.264?
H.264 is video encoding method, an alias name for MPEG-4 AVC compression, also known as MPEG-4 Part 10, defined in joint ISO/IC and ITU specification "Information technology — Coding of audio-visual objects — Part 10: Advanced Video Coding".
The specification is freely available here: http://www.itu.int/rec/T-REC-H.264-201304-I/en
x264 is a library implementing video compression and producing H.264 compatible stream.
See also:
What is ffmpeg, avcodec, x264?
Related
Whenever I searched about H.264, there is plenty information about video-encoding, media-container so forth, but why I can not find any effective source to explain what is meaning of 26 in H.26{1,2,3,4,5}?
Among other H.26x are H Series recommendations of ITU-T (ITU Telecommunication Standardization Sector), series on Audiovisual and multimedia systems.
H.261 Video codec for audiovisual services at p x 64 kbit/s
H.262 Information technology - Generic coding of moving pictures and associated audio information: Video
H.263 Video coding for low bit rate communication
H.Imp263 Implementors' Guide for ITU-T Recommendation H.263
H.264 Advanced video coding for generic audiovisual services
H.264.1 Conformance specification for ITU-T H.264 advanced video coding
H.264.2 Reference software for ITU-T H.264 advanced video coding
H.Imp264 Implementors' Guide for ITU-T Recommendation H.264
H.265 High efficiency video coding
H.265.1 Conformance specification for ITU-T H.265 high efficiency video coding
H.265.2 Reference software for ITU-T H.265 high efficiency video coding
However there are lot of others there so 26 alone does not have any special meaning.
ITU-T Recommendations by series gives another view on how the recommendations are structured:
I am trying to encode video from my webcam into a VP8 stream. Sending a WebRTC stream from my webcam using Chrome looks pretty good and doesn't use a lot of CPU power. When I try to transcode my webcam stream to VP8 (webm) using FFMPEG then it's very, very slow.
On OS X I use the following FFMPEG options to generate a VP8 webm file. The source is a 720p Facetime webcam. It drains my CPU usage (late 2011 core i7 MBP) and the quality isn't very good:
ffmpeg -f avfoundation -i 'default' -y -qmin 11 -qmax 45 -b:v 500k -cpu-used 0 -deadline realtime test.webm
Which protocol is used for WebRTC and how can Chrome be so fast? I was under the impression that VP8 cannot be done in hardware. Using modern Intel CPUs you could use QuickSync, but I guess that is H.264 only and not supported by FFMPEG.
This is actually normal. Right now the WebM Project is still relatively small, with the only major adopter being Google's YouTube streaming service.
WebM encoding [using the VP8 codec] is extremely slow, but somehow the newer VP9 codec is even harder on consumer machines. It seems like it isn't too much of a problem for Google's massive servers, but the major benefit of WebM video [its highly effective compression] is its downfall for average users.
From the WebM Project site:
Encoding WebM videos seems really slow. What are you doing about that?
Today, encoding VP8 in "best quality" mode is the slowest configuration. >Using "good quality" mode with the speed parameter set between 0 and 5 will >provide a range of speeds. We believe that we can make substantial VP8 >speed improvements, especially with your help. We increased overall VP8 >decoder performance by ~28% in our October 2010 "Aylesbury" release and are >focusing on encoder speed improvements for our next named release.
Hope this helps!
I want to automate a transcoding workflow to h.264 in the adaptive streaming containers for HLS and Microsoft Smooth Streaming and wonder what my options are.
Ideally, there's Expression Encoder Pro with the Expression SDK that I could use to do just that. However, Expression Encoder pro is no longer for sale and the non-pro version can't do h.264.
There are other h.264 encoders, in particular with x264 there's an encoder proper that's gpl-licensed. x264 really just gives a pure stream output without the container though, let alone the adaptive streaming containers I need.
I found one reasonably priced encoder called Sorenson Squeeze that appears to have all I need (and in fact can use x264 for that part of the job), but I wonder if I have other options that make more sense in terms of spending money on licenses.
I already have licenses for Adobe's Media Encoder through Creative Cloud subscriptions, but Media Encoder can't work from the command line and I don't see any support for adaptive streaming with my desired containers.
Does anybody have more ideas?
FFmpeg and/or libav can transcode to h264 and support Smooth Streaming and HLS, and run on the command line. There's a bit of a learning curve (you in practice need to have an understanding of the container formats used, GOP and fragmentation/segmentation) but they do have the features you need.
If your media is on your local machine, and you have small amounts, buying one of the tools you mentioned might be your best bet.
However, if you have lots of media and you store it on the cloud, look at cloud offerings such as Amazon Elastic Transcoder or encoding.com.
That way you get out of the box support for formats like HLS, and you don't need to worry about licensing. it is all included in their pricing which is "per use". No subscription or upfront costs.
For e.g. MPEG-DASH adaptive bitrate content you can use either tools such as x264 + MP4Box, or cloud-services like bitcodin.
I am trying to learn enough about H.264, RTP, RTSP and encapsulation file formats to develop a video recording application.
Specifically, what should I read to understand the problem?
I want to be able to answer the following questions:
Can I save H.264 packets or NALs (Per RFC 6184) to a file?
Can I save the individual payloads as files?
Can I join the RTP payloads simply by concatenating them?
What transformation is needed to save
several seconds of H.264 video in an MP4 container.
What must be done
to later join these MP4 files, or arbitrarily split them, or serve
them as a new RTSP presentation?
I want to be able to answer these questions on a fairly low level so I can implement software that does some of the processes (capture RTP streams, rebroadcast joined MP4s).
Background
The goal is to record video from a network camera onto disk. The camera has an RTSP server that provides an H.264 encoded stream which it sends via RTP to a player. I have successfully played the stream using VLC, but would like to customize the process.
The "raw" video stream is a sequence of NAL units, per H.264 specification. Neither on RTSP, nor on MP4 file you have this stream "as is".
On RTSP connection you typically receive NAL units fragmented, and you need to depacketize them (no you cannot simply concatenate):
RTP H.264 Packet Depacketizer
How to process raw UDP packets so that they can be decoded by a decoder filter in a directshow source filter
MP4 file is a container formatted file, and has its own structure (boxes). So you cannot simply stream NALs into such file and you have to do what is called multiplexing.
How do I create an mp4 file from a collection of H.264 frames and audio frames?
just install rtmpdump along with rtmpsrv and rtmpsuck...
this will do all the work
in one terminal open rtmpsrv and in other open rtmpdump -r "RTMP URL"
this will save the stream in mystream.flv
As far as i know there is no audio streaming available in html5. Even with the audio tag.
That is, you always have to provide a file instead of passing an audio stream of some sort.
So, we know that most commonly used formats are ogg and mp3(not free). Also wav can be used but due to its size not commonly used.
My question is can I fake a file as if it was a stream, say create the wav file (with the riff header) and specify the PCM format details(freq,channel,blah blah) and pass that as the first few bytes and then send the PCM stream over the wire(actualy audio chunks).
The first issue I see if that RIFF header in the wav files require the chunk sizes which is the length of the file. WELL WE DONT HAVE A LENGTH SINCE IT IS AN AUDIO STREAM.
Any ideas.
Yes, absolutely.
The client doesn't need to know or care that the media it is playing is created live, or being loaded from disk.
You may have challenges depending on the codec used. WAV present the problems you have mentioned with the header, but it should be possible. With MP3, you can generally just send data at any point, and the decoder will sync to the frames on its own.