13

Tôi cố gắng truyền phát âm thanh trực tiếp bằng ffmpegmicrô USB bên ngoài. Tôi đã làm theo hướng dẫn gần như này

Tôi đã phải điều chỉnh một số bước nhưng cuối cùng, tôi đã đạt được để nhận luồng máy tính xách tay của mình bằng lệnh này:

ffmpeg -f oss -i /dev/dsp1 -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://192.168.28.116:1234

CPU gần 100%, tôi có âm thanh không tốt trong hai giây và sau đó không có gì ... Tôi thấy trong Wireshark rằng bảng đang gửi khung liên tục.

Có ai có ý tưởng để giảm mức sử dụng CPU?

usb audio

— hotips
nguồn

Bạn có thể muốn xem xét việc ép xung và phân chia bộ nhớ khác. Nếu bạn có sự lựa chọn về codec, bạn có thể đạt được một số cải tiến bằng cách chuyển đổi. Bạn cũng có thể muốn điều tra việc nén luồng - mặc dù điều này có thể là một số lợi ích bằng không - bất cứ điều gì bạn đạt được trong thời gian chuyển có thể bị mất khi nén.

— Steve Robillard

Bạn đã thử viết vào một tập tin địa phương đầu tiên? Tôi sẽ cố gắng thực hiện từng bước: 1) ghi thời gian thực vào tệp sóng, 2) ghi thời gian thực vào tệp mp3 3) truyền phát nội dung qua mạng

— pixelistik

không phải lúc này. dường như rất phức tạp để thực hiện tất cả các bước theo cách thủ công thay vì ffmpeg hoàn toàn tự động ;-)

— hotips

Bạn đang ghi âm gì?

— Alex Chamberlain

1

Tôi đang cố gắng tạo ra một điện thoại trẻ em ethernet

— hotips

7

Để trả lời câu hỏi cụ thể của bạn, bạn có thể giảm CPU bằng cách chuyển arecord vào ffmpeg:

arecord -f cd -D plughw:1,0 | ffmpeg -i - -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://234.5.5.5:1234

Bạn sẽ cần thay thế plughw: 1,0 bằng card âm thanh cụ thể của mình. Xem arecord -l để biết thông tin. Trên Rasp Pi của tôi, nó đã tăng từ ~ 95% CPU lên ~ 35%.

— kumar303
nguồn

6

Đầu vào ALSA

Một cách khác là đi qua ALSA. Một lệnh tương tự như trên sẽ là

ffmpeg -ac 1 -f alsa -i hw:0,0 -acodec libmp3lame -ab 32k -ac 1 -re -f rtp rtp://localhost:1234

Tôi không chắc điều này sẽ ảnh hưởng đến việc sử dụng CPU như thế nào.

— Alex Chamberlain
nguồn

Tôi đã thử: ffmpeg -ac 1 - 0x7a1510] Bộ đệm ALSA xrun. Còn ý tưởng nào khác không?

— hotips

Tôi đã thử nghiệm ffmpeg -f oss -i / dev / dsp1 -ab 32k -ac 1 -re -f rtp rtp: //192.168.28.116: 1234 nhưng âm thanh rất tệ ... trên độ trễ là khoảng 6 giây. Bất kỳ ý tưởng để có một giải pháp tốt hơn?

— hotips

1

@ si2w Tôi nghĩ 32k cho mp3 là một trò đùa. Hoặc là lên, hoặc thử một codec khác. Có thể một trong những loạt G2xx được thiết kế cho điện thoại

— Alex Chamberlain

3

Điều này hoạt động và giảm sử dụng cpu:

ffmpeg -f alsa -i default:CARD=U0x46d0x819 -acodec mp2 -ac 1 -re -f rtp rtp://234.5.5.5:1234 2> /tmp/mylog.log &

Đảm bảo thay thế mặc định: CARD = U0x46d0x819 bằng ID micrô của bạn, (được lấy từ arecord -l) hoặc bạn cad chỉ định -i hw:0,0(hoặc bất kỳ thiết bị nào).

Tôi gặp một vấn đề tương tự - mã hóa mp3 chiếm 90% + năng lượng cpu và không thể theo kịp âm thanh - vì vậy tôi đã đổi nó thành mã hóa mp2. Điều này đã sử dụng khoảng 15-18% CPU (đo vi top) và truyền trơn tru đến VLC trên mạng LAN của tôi. Nó sẽ làm cho một màn hình bé hoàn hảo, hoặc bất cứ điều gì. Chỉ có một độ trễ thứ hai hoặc lâu hơn, đó là bộ đệm ở cuối VLC.

Lưu ý: Địa chỉ IP là một địa chỉ multicast ([224-239] .xyz). Bạn không cần phải nhắm mục tiêu vào một thiết bị mạng cụ thể trên mạng LAN và bộ định tuyến băng thông rộng của bạn sẽ giữ lưu lượng truy cập cục bộ (theo mặc định).

— thời gian
nguồn

2

Bạn có thể giảm đáng kể tải CPU bằng cách giảm tốc độ mẫu âm thanh của thiết bị đầu vào ( -ar 8000 trước -f alsa ) và đặt tốc độ bit âm thanh codec thành 128k ( -b:a 128k). Cũng trớ trêu thay, số lượng kênh ( -ac 1) dường như tăng tải CPU nên tôi thấy lệnh này chạy ở CPU khá thấp:

ffmpeg -ar 8000 -f alsa -i hw:0 -acodec mp2 -b:a 128k -f rtp rtp://other:4444

Mặc dù người ta cần nhớ rằng nó cũng phụ thuộc vào khả năng của phần cứng chụp mà người dùng đang cố gắng sử dụng và các phiên bản của ffmpeg / avconv.

— Cầu tàu
nguồn

Luồng âm thanh trực tiếp bằng FFMPEG

Đầu vào ALSA