With pf_block, there is, for each received packet:
- one heap allocation for the block_t,
- one memory copy from the block_t into the downstream filter/demux
(normally the prefetch filter) in the stream core, and
- one heap free in the stream core.
And it gets worse if the packet size exceeds the MRU (1316 bytes).
In practice, the read size (from the prefetch filter) is almost always
much larger than the packet size. Using pf_read, we eliminate both the
heap manipulations and the memory copies, both for sanely sized and
insanely sized fragmented packets.
In the corner case that the read size is actually small, this uses a
circular buffer and incurs one memory copy. That is still faster than
the pf_block logic.
Add second block on recvmsg() to check if we need to adjust mtu to be
higher. With this approach, we will do extra memcpy and allocation in
codepaths where mtu should be increased, but not on normal codepath.
Allocates the minimum sized overflow block to capture the maximum
sized datagram when combined with the normal (mtu sized) block.
This uses the same approach on all platforms and doesn't rely on
MSG_TRUNC in linux case and something else in other cases.
recv() needs MSG_TRUNC flag so it will tell actual data-size if truncate
would happen additional to setting flag for it.
Tested adjustment of MTU by sending data to localhost via netcat:
cat ~/tmp/myfile.mp3|netcat -u 127.0.0.1 1234
and vlc -Idummy -vv udp://@127.0.0.1:1234 --sout="#stat"
without this patch the udp input constantly complains about trunced
input and doesn't adjust the receiving amount.
udp fixup
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Do not declare *_sys_t typedefs globally in vlc_common.h. Instead,
declare them locally in each module that provides a definition.
This paves the way to move C++ definitions into anonymous namespaces in
order to respect C++ ODR.
The picture_resource_t and sout_stream_id_sys_t typedefs will be handled
separately, since they require specific additional changes.
See #18033
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
By default we wait -1 as previously, but you can give --udp-timeout as timeout in seconds
how long we wait for next packet before deciding that input has ended.
Similar than rtp input does, doing realloc from 64k->1.5k would
usually mean extra malloc+memcpy per packet.
Also don't pass buffer onward if we don't receive any useful stuff (-1)
Re-license almost all the playback modules to LGPLv2.1+ with
authorization from their respective contributors (230+)
This includes:
- access, codec, packetizers, demux
- audio filters, audio mixers, audio output
- video filters, video chroma, video output
- text renderers
- XML parser
- ARM NEON and SSE2 optimisations (mostly for chromas and filters)
Some modules are not concerned:
- BDA and DShow access modules because Manol Manolov is AWOL
- Real RTSP, because it is derived from Xine
- x264 and t140 because they are encoders only
- DLL Loader, because it is derived from MPlayer
- DTS packetizer, because Jon Lech Johansen is AWOL
- Shine and WMAfixed, because they are derived from Rockbox
- Real demuxer, as it is derived from MPlayer and Wang Bo is AWOL
- MPC demuxer, as Yavor Doganov is AWOL
- Tivo demuxer, because it is derived from an MPlayer fork
- Playlist demuxer, (WPL and ZPL parts missing), because suheaven is AWOL
- iOS audio output and video display, because author refuses the license change
- Equalizer and compressor, because Ronald Wright is AWOL
- Mono, Headphone and Dolby, because author refuses the license change
- hqdn3d and yadif, because they are from MPlayer/libavfilter
- remoteosd, because it derives from RealVNC code
- MMX optimisations, because Ollie Lho, from SiS, is AWOL
- Rotate, because it depends on GPL motion
Nota Bene:
- Some modules depend on GPL-only libraries, a LGPL module does not mean
that the resulting binary module will be LGPL.
Libraries affected would include liba52, libdvdcss, libdvdnav, libdvdread,
faad2, libdca, libmad, libmpeg2, libpostproc, SRC, sid, zvbi and probably others.
If a non-default UDP multicast destination port is used, it can and
should be specified through the MRL. Anyway, you should not use raw UDP
streaming ;-)
