Open bradsoto opened 5 years ago
updated patch to fix status text
--- src/opusenc.c
+++ src/opusenc.c
@@ -145,7 +145,7 @@
printf(" --speech Tune low bitrates for speech (override automatic detection)\n");
printf(" --comp n Set encoding complexity (0-10, default: 10 (slowest))\n");
printf(" --framesize n Set maximum frame size in milliseconds\n");
- printf(" (2.5, 5, 10, 20, 40, 60, default: 20)\n");
+ printf(" (2.5, 5, 10, 20, 40, 60, 120, default: 20)\n");
printf(" --expect-loss n Set expected packet loss in percent (default: 0)\n");
printf(" --downmix-mono Downmix to mono\n");
printf(" --downmix-stereo Downmix to stereo (if >2 channels)\n");
@@ -597,9 +597,10 @@
else if (strcmp(optarg,"20")==0) opus_frame_param=OPUS_FRAMESIZE_20_MS;
else if (strcmp(optarg,"40")==0) opus_frame_param=OPUS_FRAMESIZE_40_MS;
else if (strcmp(optarg,"60")==0) opus_frame_param=OPUS_FRAMESIZE_60_MS;
+ else if (strcmp(optarg,"120")==0) opus_frame_param=OPUS_FRAMESIZE_120_MS;
else {
fatal("Invalid framesize: %s\n"
- "Value is in milliseconds and must be 2.5, 5, 10, 20, 40, or 60.\n",
+ "Value is in milliseconds and must be 2.5, 5, 10, 20, 40, 60, or 120.\n",
optarg);
}
frame_size = opus_frame_param <= OPUS_FRAMESIZE_40_MS
@@ -1002,7 +1003,7 @@
if (data.nb_streams-data.nb_coupled>0) fprintf(stderr,
"%s%d uncoupled",data.nb_coupled>0?", ":"",
data.nb_streams-data.nb_coupled);
- fprintf(stderr,")\n %0.2gms packets, %0.6g kbit/s%s\n",
+ fprintf(stderr,")\n %0.3gms packets, %0.6g kbit/s%s\n",
frame_size/(48000/1000.), bitrate/1000.,
with_hard_cbr?" CBR":with_cvbr?" CVBR":" VBR");
fprintf(stderr," Preskip: %d\n",lookahead);
Packet sizes larger than 60 ms can be useful with RTP or other scenarios where each Opus packet is sent as a network packet, because network packets can include a large amount of per-packet overhead. opusenc only writes to Ogg Opus files, which do not have that issue; in fact the overhead will usually be a little less with more smaller packets, because the Ogg container is optimized for small packets (especially those under 255 bytes). So the advantage of larger packets is lost, and the disadvantages such as loss of encoder flexibility remain (all frames in the packet must be encoded with the same configuration). Is there a reason that you want to create 120 ms packets with opusenc?
I'd like to use Opus with HTTP live streaming or DASH, but now that I've read your explanation I'm not too sure if splitting the audio in 960ms-chunks is the best way to implement it.
On Sat, Feb 23, 2019, 12:25 PM mark4o notifications@github.com wrote:
Packet sizes larger than 60 ms can be useful with RTP or other scenarios where each Opus packet is sent as a network packet, because network packets can include a large amount of per-packet overhead. opusenc only writes to Ogg Opus files, which do not have that issue; in fact the overhead will usually be a little less with more smaller packets, because the Ogg container is optimized for small packets (especially those under 255 bytes). So the advantage of larger packets is lost, and the disadvantages such as loss of encoder flexibility remain (all frames in the packet must be encoded with the same configuration). Is there a reason that you want to create 120 ms packets with opusenc?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/xiph/opus-tools/issues/44#issuecomment-466682403, or mute the thread https://github.com/notifications/unsubscribe-auth/ABeDkzgfys1vXFY4XGeipHaIMv1M2-ySks5vQZWNgaJpZM4aiKb7 .
There are other frame lengths defined in the API, but for now I'm only interested in 120ms. Since 1.2 we can do 120ms frames natively.
https://gist.github.com/bradsoto/0259776305179712f534b133013c5815