I have a pcap trace with some scrambled Mpeg-ts data. I want to know if the ECM data is coming with it or not?
With the normal Wireshark MPEG-ts dis-sector I am not able to see that. So, is there any way to do so?
I have tried some Mpeg-TS readers by extracting the Mpeg data from pcap, but i am not able to find out if ECM is there or not?
Also, i think ECM can be In-band and out-band So, if its out-band, how a i come to know the same?
I have some PIDs inside the Mpeg headers, but I am not sure which PID refers to the ECM data and how will i be able to detect that.
You will need to know pid of PMT, with format of PMT packet, you can know ECM pid, and check if any packets with ECM are there.
Related
I'm writing a player for an RTMP stream using the ffmpeg API. I know the usual way to get the stream info into an input format is with avformat_find_stream_info. And that works. However, because it's RTMP it takes a long time for it to scan enough of the stream to pick up the info. I've played with max_analyze_duration and probesize and it's a bit better, but it still takes 10-15 seconds to load. That's way too long for my application.
But I'm the one making the stream on the other end, so I know exactly what's in it. It seems like it would make more sense for me to tell the input format what the stream info is rather than asking it to search for it. But I can't find any examples of this, and my attempts to use avformat_new_stream with an input format aren't working.
Does anyone know if this is possible? And if so, could you point me in the direction of how?
Thanks!
This is what is known as an XY problem
Yes, you can spoof the sequence header (assuming h.264/aac). But it won't accomplish what you want. What is happening is your RTMP server (reflector) is eating the first GOP. So even if the analyze was done faster, you must first wait for the first video key frame anyway.
You need to configure your RTMP server to send the full GOP (in nginx+rtmp the setting is wait_key on)
I'd like to capture multiple real-time video streams arriving on rtp protocol, using ffmpeg. When I initiate the recording, by issuing the ffmpeg <command line parameters> command, it always takes a while for the connection to built up and the actual recording to begin. This might be more than 2 seconds in certain cases, which cause a constant time difference at the replay.
How can I extract the information containing the time of the first actually recorded frame from ffmpeg? If it's not possible with ffmpeg without editing the source (which I did, and would like to avoid for other reasons), is there any similar multi-platform open-source tool which could be used?
Not possible without effort on your side. Use something like live555 to capture your streams. All your sources must synchronize to a single clock using ntp and then rtp timestamps can be used at the receiver end to synchronize the various streams. This is not trivial and is used in video conferencing systems. I am not aware of any free implementation of the same.
If you do not have control over the sources then you are out of luck because there is no such things as a common base time across the streams. If you do, you still need to modify live555 and your player to synchronize using the timestamps on the streams and the ntp clock. Like I said, not trivial.
Perhaps gstreamer might already have plugins for it, its been a while since I used it so I am not sure. You could take a look there. (gstreamer.net).
I'm searching for a way to analyse the content of internet radios. I want to write a ruby client that can get the current track, next track, band, bpm and other meta information from a stream (e.g. a radio on shoutcast).
Does anybody know how to do this? And how do I record that stream into a mp3 or aac file?
Maybe there is a library that can already do this, I haven't one so far.
regards
I'll answer both of your questions.
Metadata
What you are seeking isn't entirely possible. Information on the next track is not available (keep in mind not all stations are just playing songs from a playlist... many offer live content). Advanced metadata such as BPM is not available. All you get is something like this:
Some Band - Some Song
The format of {artist} - {song title} isn't always followed either.
With those caveats, you can get that metadata from a stream by connecting to the stream URL and requesting the metadata with the following request header:
Icy-MetaData: 1
That tells the server to send the metadata, which is interleaved into the stream. Every 8KB or so (specified by the server in a response header), you'll find a chunk of metadata to parse. I have written up a detailed answer on how to parse that here: Pulling Track Info From an Audio Stream Using PHP The prior question was language-specific, but you will find that my answer can be easily implemented in any language.
Saving Streams to Disk
Audio playing software is generally very resilient to errors. SHOUTcast servers are built on this principal, and are not knowledgeable about the data going through them. They just receive data from an encoder, and when the client requests the stream, they start sending that data at an arbitrary point.
You can use this to your advantage when saving stream data. It is possible to simply write the stream data as it comes in to a file. Most audio players will play them without problem. I have tested this with MP3 and AAC.
If you want a more conformant file, you will have to use a library or parse the stream yourself to split on the appropriate frames, and then handle bit reservoir issues in your code. This is a lot of work, and generally isn't worth doing unless you find your files have real compatibility problems.
Is there any way to insert User Data (Start code = 0X1B2) in a MPEG stream?
What I am looking for is a simple tool, script or some tips using and Hex Editor...
Or you may have a patch for ffmpeg (libavcodec and libavformat) that allows to do that?
If you're going to insert user data into a Transport Stream, the easiest solution is when it is in a PID of its own not overlapping with any of the existing PIDs in the stream - where you need not worry about adjusting the continuity counter of the original stream packets following the insertion points.
But it is really impossible to make assumptions about what PIDs you can expect in a TS stream, and if you're trying to generalize it - you would need to take care of adjusting the continuity counter in the TS header for packets of the same PID.
What i want to do is the following procedure:
Get a frame from the Webcam.
Encode it with an H264 encoder.
Create a packet with that frame with my own "protocol" to send it via UDP.
Receive it and decode it...
It would be a live streaming.
Well i just need help with the Second step.
Im retrieving camera images with AForge Framework.
I dont want to write frames to files and then decode them, that would be very slow i guess.
I would like to handle encoded frames in memory and then create the packets to be sent.
I need to use an open source encoder. Already tryed with x264 following this example
How does one encode a series of images into H264 using the x264 C API?
but seems it only works on Linux, or at least thats what i thought after i saw like 50 errors when trying to compile the example with visual c++ 2010.
I have to make clear that i already did a lot of research (1 week reading) before writing this but couldnt find a (simple) way to do it.
I know there is the RTMP protocol, but the video stream will always be seen by one peroson at a(/the?) time and RTMP is more oriented to stream to many people. Also i already streamed with an adobe flash application i made but was too laggy ¬¬.
Also would like you to give me an advice about if its ok to send frames one by one or if it would be better to send more of them within each packet.
I hope that at least someone could point me on(/at?) the right direction.
My english is not good maybe blah blah apologies. :P
PS: doesnt has to be in .NET, it can be in any language as long as it works on Windows.
Many many many many thanks in advance.
You could try your approach using Microsoft's DirectShow technology. There is an opensource x264 wrapper available for download at Monogram.
If you download the filter, you need to register it with the OS using regsvr32. I would suggest doing some quick testing to find out if this approach is feasible, use the GraphEdit tool to connect your webcam to the encoder and have a look at the configuration options.
Also would like you to give me an advice about if its ok to send frames one by one or if it would be better to send more of them within each packet.
This really depends on the required latency: the more frames you package, the less header overhead, but the more latency since you have to wait for multiple frames to be encoded before you can send them. For live streaming the latency should be kept to a minimum and the typical protocols used are RTP/UDP. This implies that your maximum packet size is limited to the MTU of the network often requiring IDR frames to be fragmented and sent in multiple packets.
My advice would be to not worry about sending more frames in one packet until/unless you have a reason to. This is more often necessary with audio streaming since the header size (e.g. IP + UDP + RTP) is considered big in relation to the audio payload.