I've been reading the documentation but it's a little tough to see how to set up a pipeline in C++ using the UDP source element.
If anyone knows of an example, or could post a snippet showing how to do it, I'd be very grateful.
Is it enough to do
source = gst_element_make_from_uri(GST_URI_SRC, "udp://#:15004", "source");
and then use the result as the first element in a pipeline?
User otopolsky answered this adequately for my purposes in the comment above, saying:
here are rtp examples, I think they work very similar (RTP is UDP based protocol with packet counting ability), why dont you just use udpsrc? – otopolsky Jan 28 at 8:21
Related
I'm working on a server whereas a fun thing for late December I want to make the whole world darker. The Minecraft sun usually has a light level of 15. Is there any way to lower the sun's light level to something like 8 so mobs can spawn on any block not under sunlight?
Any solution like datapacks, commands, or server plugins would work, but I wouldn't be able to use any mods (it could be super simple if I could use mods, but others would have to download it).
Thanks.
So I found this plugin online, which basically allows you to change light levels for things at will, and might solve your problem. If it doesn't, I also found this forum post, which may also help(but it is a bit more complex). It suggests decompiling Bukkit.jar(or whatever server software you use, Spigot, Paper, etc.), then editing the code for which mobs can spawn in.
I'd suggest looking into ProtocolLib plugin to send packets to players. I don't know which packet lighting would be in but if you use a tool called "pakkit" (https://github.com/Heath123/pakkit) you can watch Minecraft packets and that might help you see what causes light changes (example: place a torch in front of you and see what packet is sent). Then if you know what packets are sent you can modify packets as they are sent to include custom lighting data.
I am experimenting with a custom implementation of a "Correlate Access Code Tag" block and I am getting a "Missing a required length tag on port 0 at item #0" when I connect its output to a "Repack Bits" or to a "Tagged Stream to PDU".
Bitstream -> Correlate Access Code Tag -> Repack Bits -> Tagged Stream
to PDU
My idea was to examine a stream of bits until I find the access code. Then, read the following bits to get the length of the packet. Finally, knowing the length of the packet I thought I could just add a tag as "packet_length: x ", so that the following blocks understood that they have to pack the next x bits after the tag as a pdu.
However, taking a look at the error I get and reading a little bit, I think I am misunderstanding how to use the tags. So I wanted to ask whether the tagged stream I am producing (with tags at irregular and arbitrary intervals, whenever I find the access code) is really a tagged stream.
My other idea is that maybe the error is in the fact that my "Correlate Access Code Tag" block is outputing samples no matter if they have a tag or not. In that case, some samples without tags are going to reach the blocks that expect tagged streams before one tag arrives. Should I just start outputting samples after I find the access code and therefore make sure that the first sample always has a tag?. If so, wouldn't it be easy to just keep reading bits and build the pdu inside the "Correlate Access Code Tag" block directly?. Also, am I correct if I say that it makes no sense to solve variable length tasks with tags?
If you think that none of the options that I mentioned (tagged streams vs build the pdu within the access code block) are suitable for this variable length task, I would appreciate if you could point me in the right direction.
I am sorry for the noob questions, but I am a little bit stuck with this.
Thanks in advance :)
I want to know the sample code for sending message to server and get back response to verifone vx520 terminal using ISO 8583.
As noted in a comment on your question, this is not a code sharing site, so such an open-ended question is a bit difficult to answer, but perhaps I can get you started on the right foot.
First of all, let me start by suggesting that if you have control over the terminal code and the server that it will be talking to, I suggest you NOT use ISO8583. Yes, it's an industry standard and yes, it communicates data efficiently, BUT it is much more difficult to use than, say, VISA-1 or XML, or JSON etc. That means you have more opportunities for bugs to creep into your code. It also means that if something goes wrong, it takes a lot more effort to try and figure out what happened and try and fix it. I have used all these protocols and others besides and I'll tell you that ISO8583 is one of my least favorite to work with.
Assuming you do not have a choice and you must use ISO8583 then it's worth noting that ISO8583 is nothing but a specification on how to assemble data packets in order to communicate. There is nothing special about the Vx520 terminal (or any other VeriFone terminal) that would change how you would implement it verses how you might do so on any other C++ platform EXCEPT that VeriFone DOES provide you with a library for working with this spec that you are free to use or ignore as you see fit.
You don't need to use this library at all. You can roll your own and be just fine. You can find more information on the specification itself at Wikipedia, Code Project, and several other places (just ask your favorite search engine). Note that when I did my 8583 project, this library was not available to me. Perhaps I wouldn't have hated this protocol so much if I had had access to it... who knows?
If you are still reading this, then I'll assume that ISO8583 is a requirement (or you are a glutton for punishment) and that you are interested in trying out this engine that VeriFone has provided.
The first thing you will need to do (and hopefully, you have already done it) is to install ACT as part of the development suite (I also suggest you head over to DevNet and get the latest version of ACT before you get started...). Once installed, the library header can be found at %evoact%\include\iso8583.h. Documentation on how to use it can be found at %evoact%\docs. In particular, see chapter 6 of DOC00310_Verix_eVo_ACT_Programmers_Guide.pdf.
Obviously, trying to include a whole chapter's worth of information here would be out of scope, but to give you a high-level idea of how the engine works, allow me to share a couple excerpts:
This engine is designed to be table driven. A single routine is used
for the assembly and disassembly of ISO 8583 packets. The assembly and
disassembly of ISO 8583 packets is driven by the following structures:
Maps One or more collections of 64 bits that drive packet assembly and
indicate what is in a message.
Field table Defines all the fields used
by the application.
Convert table Defines data-conversion routines.
Variant tables Optional tables used to define variant fields.
The process_8583() routine is used for the assembly and disassembly of ISO
8583 packets.
An example of using process_8583() is given elsewhere as follows:
#include "appl8583.h"
int packet_sz;
void assemble_packet ()
{
packet_sz = process_8583 (0, field_table, test_map, buffer, sizeof( buffer));
printf ("\ fOUTPUT SIZE %d", packet_sz);
}
void disassemble_packet ()
{
packet_sz = process_8583 (1, field_table, test_map, buffer, packet_sz);
printf ("\ fINPUT NOT PROCESSED %d", packet_sz);
}
To incorporate this engine into an application, modify the APPL8583.C
and APPL8583.H files so that each has all the application variables
required in the bit map and set up the map properly. Compile
APPL8583.C and link it with your application and the ISO 8583 library.
Use the following procedures to transmit or receive an ISO 8583 packet
using the ISO 8583 Interface Engine:
To transmit an ISO 8583 packet
1 Set data values in the application variables for those to transmit.
2 Call the prot8583_main() routine. This constructs the complete
message and returns the number of bytes in the constructed message.
3 Call write() to transmit the message.
To receive a message
1 Call read() to receive the message.
2 Call the process_8583() routine. This results in all fields being
deposited into the application variables.
3 Use the values in the application variables.
I have made a software that uses WebRTC DSP libraries (AEC, NS, AGC, VAD). Now I need to know what algorithm uses each one to write my Master´s Thesis, but I don't find any information about that.
Someone knows the algorithms of this libraries, specially the Acoustic Echo Cancellation (like for example NLMS, that I know it's commonly used, but I don't know if WebRTC also uses it).
I've tryed to know the algorithm looking into the source code, but I don't understand enough.
Thanks in advance!
I've just successfully using standalone WebRTC aecm module for android. and there's some tips:
1.the most important is the thing called "delay", you can find the definition of it in dir:
..\src\modules\audio_processing\include\audio_processing.h
quote:
Sets the |delay| in ms between AnalyzeReverseStream() receiving a
far-end frame and ProcessStream() receiving a near-end frame
containing the corresponding echo. On the client-side this can be
expressed as delay = (t_render - t_analyze) + (t_process - t_capture)
where,
t_analyze is the time a frame is passed to AnalyzeReverseStream() and t_render is the time the first sample of the same frame is
rendered by the audio hardware.
t_capture is the time the first sample of a frame is captured by the audio hardware and t_pull is the time the same frame is passed to
ProcessStream().
if you wanna use aecm module in standalone mode, be sure you obey this doc strictly.
2.AudioRecord and AudioTrack sometimes block(due to minimized buffer size), so when you calc the delay, don't forget adding blocking time to it.
3.if you don't know how to compile aecm module, you may learn Android NDK first, and the module src path is
..\src\modules\audio_processing\aecm
BTW, this blog may help a lot in native dev. and debuging.
http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-development/
http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-debugging/
hope this may help you.
From the code inspection of AGC algorithm in WebRtc, it matches closely with the description in http://www.ti.com/lit/wp/spraal1/spraal1.pdf
It's based on NLMS, but has a variable step length (mu).
I am having to reference MPEG-2 code. My application needs analyze I-frames. Looking at the code I am unable to figure out how exactly this can be done.
Basically I want to extract the first or second I-frame. How do I do that and where do I find the information regarding the frame type?
I would appreciate any direction on this.
I Just wrote this answer: Can you find key frame (I-frame) in h264 video without decoding? i.e. is it in packet?
which applies to you just as well.
The start code of picture in MPEG2 is 0x00 .
Further, you can see byte 5 - to identify the picture type.
See here: http://dvd.sourceforge.net/dvdinfo/mpeghdrs.html