SIPp returns error like "Ignoring non IP{4,6} packet!" - sip

I am trying to play out some audio with rtp-nte dtmf to a cisco router. I
get the following error:
root#sipper:~# sipp -sf /root/aaravi-sip.xml -s 911 -i 10.106.106.72 -m 1 -pause_msg_ign -trace_msg -trace_shortmsg -f 1 -l 10000 -trace_err -trace_stat -trace_rtt -trace_logs -trace_screen -s 911 10.106.106.69
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
Ignoring non IP{4,6} packet!
I can see some discussions on the internet. But, no one seems to have posted
a solution. I could share the pcap file I was using.. Default pcaps and dtmf
samples work fine.!

The type of pcap used in the SIPp should be 'Ethernet'. But when the packet is captured by tcpdump or wireshark, the packet type will 'Linux "cooked"'.
The type of pcap can be checked by the following command
root#sipper:~# file sample.pcap
sample.pcap: extended tcpdump capture file (little-endian) - version 2.4 (Linux "cooked", capture length 262144)
The linux cooked pcap can be converted to ethernet by using the following command
tcprewrite --dlt=enet -i sample.pcap -o sample-out.pcap

Related

ffmpeg trailing options with colon on windows

I've just switched to Windows 10 Pro.
When I open a shell to use ffmpeg, any time I use an option with a colon I get an error.
for example:
ffmpeg -thread_queue_size 4096 -r 24 -i uncompressed.mov -c:v libx264 -b:v 40m -profile:v main -crf 31 -pix_fmt yuv420p -c:a aac -b:a 192K -strict -2 -vf eq=saturation=1.3 compressed_31.mp4
gives:
[NULL # 0000023184ac8c40] Unable to find a suitable output format for 'libx264'
libx264: Invalid argument
if I get rid of -c:v libx264, then I get the same error with '40m', or with 'main' etc... so it's always trying to read the argument after an option with a colon as the output file.
Is this a windows thing? All my commands work fine in a mac terminal.
I assume the answer is simple. Apologies for my ignorance. Feels like I'm misunderstanding the windows shell or ffmpeg on windows.

How to http stream FFMPEG encoded frames with VLC

I have a python script that write images (numpy arrays) on the standard output.
I want to keep this frames and encode them h264 with FFMPEG, using GPU, then give it to vlc to expose a stream over http.
Here there's a working example of my apporach, without the part of h264 encoding:
python3 script.py | ffmpeg -r 24 -s 1920x1080 -f rawvideo -i - -vcodec copy -f avi - | cvlc --demux=rawvideo --rawvid-fps=25
--rawvid-width=1920 --rawvid-height=1080 --rawvid-chroma=RV24 - --no-audio --sout '#transcode{vcodec=MJPG,venc=ffmpeg{strict=1}}:standard{access=http{user=pippo,pwd=pluto,mime=multipart/x-mixed-replace;boundary=--7b3cc56e5f51db803f790dad720ed50a},mux=mpjpeg,dst=:10001/}'
Now, I'm having troubles in writing working pipes to do what I need.
Here the pipe I'm actually working on, FFMPEG process is managed by GPU, but VLC cannot correctly manage the flow, I suppose, in fact I can connect to VLC from another VLC instance used as client, but then I got an error in which VLC client cannot open MRL.
Here the pipe:
python3 script.py | ffmpeg -y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda -f rawvideo -s 1920x1080 -i - -c:a copy -c:v h264_nvenc -f h264 - | cvlc --demux=rawvideo --rawvid-fps=25 --rawvid-width=1920 --rawvid-height=1080 --rawvid-chroma=RV24 - --no-audio --sout '#transcode{vcodec=MJPG,venc=ffmpeg{strict=1}}:standard{access=http{user=pippo,pwd=pluto,mime=multipart/x-mixed-replace;boundary=--7b3cc56e5f51db803f790dad720ed50a},mux=mpjpeg,dst=:10001/}'
I don't understand how to set vlc parameters in order to manage the incoming stream. I also could have made errors in ffmpeg pipe, any suggestion is welcome.

FFmpeg VP9 - Different Quantisation Parameters but same output files

I want to encode a video with vp9 with different quantisation parameters (qp=[16,20,24,28,32]). Unfortunately the output files have the same data rate after encoding and don't show any quality differences.
This is my code for qp=20:
ffmpeg -s:v 3840x1920 -framerate 30 -i video_3840x1920_30fps_8bit_420_erp.yuv -c:v libvpx-vp9 -qp 20 -f avi out.avi
Many thanks for any pointers you can give me.
-qp only works for internal mpegvideoenc-derived encoders, such as FFmpeg's built-in MPEG-1/2/4 encoders. Libvpx, like x264/5, uses -crf to do this instead. See the Wiki for more details. You can also type ffmpeg -h encoder=libvpx-vp9:
$ ffmpeg -h encoder=libvpx-vp9
[..]
-crf <int> E..V.... Select the quality for constant quality mode (from -1 to 63) (default -1)
So for qp=20, you would use ffmpeg -s:v 3840x1920 -framerate 30 -i video_3840x1920_30fps_8bit_420_erp.yuv -c:v libvpx-vp9 -crf 20 -b:v 0 out.avi.

Generating 64kbps audio-only mpegts for HTTP Live segmenter to meet 64kbps audio only requirement

I am trying to convert our mp4 files into mpeg-ts and segment it into .ts files for my iphone app to play. I am using Carson McDonalds's HTTP-Live-Video-Stream-Segmenter-and-Distributor to do that.
I got his stuff complied and working correctly. I am currently trying to meet Apple's requirement where I need to provide a baseline 64 kbps audio only stream to my m3u8 playlist.
Carson doesn't seem to have a profile for that.
I need to be able to generate 64kbps audio-only stream from mp4, and turn that into mpeg-ts for the segmenter into ts. I am trying to find the right ffmpeg command that will validate without problem using Apple's mediastreamvalidator.
So far I modified an existing encoding profile to try to achieve 64kbps total:
ffmpeg -er 4 -i %s -f mpegts -acodec libmp3lame -ar 22050 -ab 32k -s 240x180 -vcodec libx264 -b 16k -flags +loop+mv4 -cmp 256 -partitions +parti4x4+partp8x8+partb8x8 -subq 7 -trellis 1 -refs 5 -coder 0 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 64k -maxrate 16k -bufsize 16k -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect 4:3 -r 10 -g 30 -async 2 - | %s %s %s %s %s
but then when I try to validate it using mediastreamvalidator, it gives error after few ts:
Playlist Validation: OK
Segments:
sample_cell_4x3_64k-00001.ts:
WARNING: Media segment exceeds target duration of 10.00 seconds by 1.30 seconds (segment duration is 11.30 seconds)
sample_cell_4x3_64k-00002.ts:
WARNING: Media segment exceeds target duration of 10.00 seconds by 1.40 seconds (segment duration is 11.40 seconds)
....
....
sample_cell_4x3_64k-00006.ts:
ERROR: (-1) Unknown video codec: 1836069494 (program 0, track 0)
ERROR: (-1) failed to parse segment as either an MPEG-2 TS or an ES
sample_cell_4x3_64k-00007.ts:
ERROR: (-1) Unknown video codec: 1836069494 (program 0, track 0)
ERROR: (-1) failed to parse segment as either an MPEG-2 TS or an ES
....
....
Average segment duration: 10.26 seconds
Average segment bitrate: 376797.92 bps
Average segment structural overhead: 349242.17 bps (92.69 %)
Is there someway I can generate this correctly with just audio which totals 64kbps and turn it into mpeg-ts ready to be segmented and validated correctly?
Am I approaching the problem right?
I don't remember all the details of Carson's ruby scripts, but the first thing I would do to get an audio-only stream is to stop the video processing (-vn). So something like this:
ffmpeg -er 4 -i %s -f mpegts -acodec libmp3lame -ar 22050 -ab 32k -vn - | %s %s %s %s %s

How to remove Ethernet layer from a pcap file?

I have a pcap captured with Wireshark. Is there any function in Wireshark that will strip Ethernet layer from the result? Or any command line tool to do it?
I searched a bit more about pcap editors, and I found that this works:
$ bittwiste -I a.pcap -O b.pcap -M 12 -D 1-14
-M 12 sets link type to RAW
-D 1-14 deletes bytes 1-14 in link data layer (Etherenet frame is 14 bytes long)
When I open up result in Wireshark I see "Raw packet data (No link information available)" and IP frame below. So this is what I needed.