search

sipwise / rtpengine

The Sipwise media proxy for Kamailio
GNU General Public License v3.0
762 stars 358 forks source link

codec issue with ilbc30 mode #854

Closed StellaTeam closed 4 years ago

StellaTeam commented 4 years ago

Hello,

We successfully manage rtpengine with forwarding and most of transcoding, but we're actually facing an issue with iLBC transcoding but only in 30ms mode.

It looks like transcoding lib was not aware of the mode to use (and defaulting to 20ms mode). We suppose it might be related to rtpengine not forwarding parameters to ffmpeg libraries because of not being able to compute them, because of these differences:

OPUS: DEBUG: [1681185779-5060-23@BJC.BGI.C.CEH]: Encoder created with clockrate 48000, 2 channels, using sample format 1 (ptime 20 for 960 samples per frame and 960 samples (0 bytes) per packet, bitrate 32000) => bitrate is non zero value (bytes is 0 but that doesn't seem to disturb opus transcoding)

ILBC: DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Encoder created with clockrate 8000, 1 channels, using sample format 1 (ptime 20 for 160 samples per frame and 160 samples **(0 bytes) per packet, bitrate 0**) => bitrate is 0

I have no idea on how to help rtpengine better compute coder/decoder parameters from its flags or if any parameter might help to solve this issue.

Please let us know if there is anything we can try.

Thanks

Below are 3 call samples.

END OF CALL

INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: Closing call due to timeout INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: Final packet stats: INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: --- Tag '119101620', created 1:05 ago for branch '', in dialogue with '3787788786' INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: ------ Media #1 (audio over RTP/AVP) using opus/48000/2 DEBUG: [1681185779-5060-23@BJC.BGI.C.CEH]: freeing send_timer INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30266 <> 192.168.2.247:5004 , SSRC 3a262ebb, 144 p, 8996 b, 0 e, 61 ts DEBUG: [1681185779-5060-23@BJC.BGI.C.CEH]: freeing send_timer INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30267 <> 192.168.2.247:5005 (RTCP), SSRC 3a262ebb, 4 p, 228 b, 0 e, 61 ts INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: --- Tag '3787788786', created 1:05 ago for branch '', in dialogue with '119101620' INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: ------ Media #1 (audio over RTP/AVP) using PCMA/8000 DEBUG: [1681185779-5060-23@BJC.BGI.C.CEH]: freeing send_timer INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30250 <> 192.168.2.249:3000 , SSRC 57fa2fe3, 156 p, 26832 b, 0 e, 62 ts DEBUG: [1681185779-5060-23@BJC.BGI.C.CEH]: freeing send_timer INFO: [1681185779-5060-23@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30251 <> 192.168.2.247:5005 (RTCP), SSRC 6ed5d7c1, 1 p, 12 b, 0 e, 64 ts DEBUG: [1681185779-5060-23@BJC.BGI.C.CEH]: __free_ssrc_handler WARNING: [1681185779-5060-23@BJC.BGI.C.CEH]: av_log: 1 frames left in the queue on closing DEBUG: [1681185779-5060-23@BJC.BGI.C.CEH]: __free_ssrc_handler

- the second one is with ILBC in 20ms mode, no problem too (except parameters not well computed)

INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: Received command 'offer' from 127.0.0.1:38743 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Dump for 'offer' from 127.0.0.1:38743: { "sdp": "v=0 o=1000 8000 8000 IN IP4 192.168.2.247 s=SIP Call c=IN IP4 192.168.2.247 t=0 0 m=audio 5004 RTP/AVP 97 0 101 a=sendrecv a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16,32-36,54 ", "ICE": "remove", "flags": [ "SIP-source-address", "codec-mask-all", "codec-transcode-PCMA", "codec-transcode-PCMU" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [ "demux" ], "call-id": "1144681428-5060-24@BJC.BGI.C.CEH", "received-from": [ "IP4", "192.168.2.247" ], "from-tag": "1451041369", "command": "offer" } NOTICE: [1144681428-5060-24@BJC.BGI.C.CEH]: Creating new call DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Codec 'PCMA/8000' added for transcoding with payload type 8 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Codec 'PCMU/8000' added for transcoding with payload type 0 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Default sink codec is iLBC/8000 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: 0 DTMF sink entries DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Creating codec handler for PCMA/8000 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Sink does not support codec PCMA/8000 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Created transcode context for PCMA/8000 -> iLBC/8000 with DTMF output -1 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Creating SSRC transcoder from PCMA/8000/1 to iLBC/8000/1 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Initialized encoder with frame size 160 samples DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Encoder created with clockrate 8000, 1 channels, using sample format 1 (ptime 20 for 160 samples per frame and 160 samples (0 bytes) per packet, bitrate 0) DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Creating codec handler for PCMU/8000 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Sink supports codec PCMU/8000 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Using passthrough handler for PCMU/8000 INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: Enabling transcoding engine DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: __free_ssrc_handler DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Using passthrough handler with new SSRC for PCMU/8000 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: creating send_timer DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: creating send_timer DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: creating send_timer DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: creating send_timer DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: set FILLED flag for stream 192.168.2.247:5004 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: set FILLED flag for stream 192.168.2.247:5005 INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: Replying to 'offer' from 127.0.0.1:38743 (elapsed time 0.001136 sec) DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: Response dump for 'offer' to 127.0.0.1:38743: { "sdp": "v=0

END OF CALL

INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: Closing call due to timeout INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: Final packet stats: INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: --- Tag '1451041369', created 1:06 ago for branch '', in dialogue with '1677325921' INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: ------ Media #1 (audio over RTP/AVP) using iLBC/8000 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: freeing send_timer INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30298 <> 192.168.2.247:5004 , SSRC 4d5011cb, 271 p, 13550 b, 0 e, 60 ts DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: freeing send_timer INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30299 <> 192.168.2.247:5005 (RTCP), SSRC 4d5011cb, 2 p, 84 b, 0 e, 60 ts INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: --- Tag '1677325921', created 1:06 ago for branch '', in dialogue with '1451041369' INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: ------ Media #1 (audio over RTP/AVP) using PCMA/8000 DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: freeing send_timer INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30278 <> 192.168.2.249:3000 , SSRC 36d73de4, 281 p, 48332 b, 0 e, 60 ts DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: freeing send_timer INFO: [1144681428-5060-24@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30279 <> 192.168.2.249:3001 (RTCP), SSRC 36d73de4, 2 p, 96 b, 0 e, 63 ts DEBUG: [1144681428-5060-24@BJC.BGI.C.CEH]: __free_ssrc_handler


- the last was done with iLBC in 30ms mode, the sound not understandable on PCMA receiving side (glitches - robotic), and no sound at all on the iLBC sender (probably dropping invalid packets)

INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: Received command 'offer' from 127.0.0.1:38743 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Dump for 'offer' from 127.0.0.1:38743: { "sdp": "v=0 o=1000 8000 8000 IN IP4 192.168.2.247 s=SIP Call c=IN IP4 192.168.2.247 t=0 0 m=audio 5004 RTP/AVP 97 0 101 a=sendrecv a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30 a=ptime:30 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16,32-36,54 ", "ICE": "remove", "flags": [ "SIP-source-address", "codec-mask-all", "codec-transcode-PCMA", "codec-transcode-PCMU" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [ "demux" ], "call-id": "1896454419-5060-25@BJC.BGI.C.CEH", "received-from": [ "IP4", "192.168.2.247" ], "from-tag": "1883495105", "command": "offer" } NOTICE: [1896454419-5060-25@BJC.BGI.C.CEH]: Creating new call DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Codec 'PCMA/8000' added for transcoding with payload type 8 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Codec 'PCMU/8000' added for transcoding with payload type 0 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Default sink codec is iLBC/8000 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: 0 DTMF sink entries DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Creating codec handler for PCMA/8000 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Sink does not support codec PCMA/8000 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Created transcode context for PCMA/8000 -> iLBC/8000 with DTMF output -1 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Creating SSRC transcoder from PCMA/8000/1 to iLBC/8000/1 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Initialized encoder with frame size 240 samples DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Encoder created with clockrate 8000, 1 channels, using sample format 1 (ptime 30 for 240 samples per frame and 240 samples (0 bytes) per packet, bitrate 0) DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Creating codec handler for PCMU/8000 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Sink supports codec PCMU/8000 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Using passthrough handler for PCMU/8000 INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: Enabling transcoding engine DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: __free_ssrc_handler DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Using passthrough handler with new SSRC for PCMU/8000 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: creating send_timer DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: creating send_timer DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: creating send_timer DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: creating send_timer DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: set FILLED flag for stream 192.168.2.247:5004 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: set FILLED flag for stream 192.168.2.247:5005 INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: Replying to 'offer' from 127.0.0.1:38743 (elapsed time 0.000799 sec) DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: Response dump for 'offer' to 127.0.0.1:38743: { "sdp": "v=0 o=1000 8000 8000 IN IP4 192.168.2.2 s=SIP Call c=IN IP4 192.168.2.2 t=0 0 m=audio 30316 RTP/AVP 8 0 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=sendrecv a=rtcp:30317 a=ptime:30 ", "result": "ok" }

INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: Closing call due to timeout INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: Final packet stats: INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: --- Tag '1883495105', created 1:07 ago for branch '', in dialogue with '854941160' INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: ------ Media #1 (audio over RTP/AVP) using iLBC/8000 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: freeing send_timer INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30334 <> 192.168.2.247:5004 , SSRC 2cbf47f2, 176 p, 10912 b, 0 e, 60 ts DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: freeing send_timer INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30335 <> 192.168.2.247:5005 (RTCP), SSRC 2cbf47f2, 2 p, 60 b, 0 e, 60 ts INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: --- Tag '854941160', created 1:07 ago for branch '', in dialogue with '1883495105' INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: ------ Media #1 (audio over RTP/AVP) using PCMA/8000 DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: freeing send_timer INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30316 <> 192.168.2.249:3000 , SSRC 36602924, 210 p, 52920 b, 0 e, 60 ts DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: freeing send_timer INFO: [1896454419-5060-25@BJC.BGI.C.CEH]: --------- Port 192.168.2.2:30317 <> 192.168.2.249:3001 (RTCP), SSRC 36602924, 2 p, 96 b, 0 e, 65 ts DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: free_ssrc_handler DEBUG: [1896454419-5060-25@BJC.BGI.C.CEH]: free_ssrc_handler

rfuchs commented 4 years ago

I don't have a functioning test bed for iLBC so I can only speculate. There's no mention of any codec-specific parameters in the ffmpeg docs, but ffmpeg -h encoder=ilbc says that there's a mode setting to select between 20 and 30 ms frames. With that in mind, and again purely speculatively and without a way to test this, I've uploaded 72e2ffa1 (branch rfuchs/ilbc-mode) which could possibly fix this.

StellaTeam commented 4 years ago

Thank you @rfuchs for your so quick reply.

Your patch has made some improvements, now, the ILBC side well receive sound (before there was no sound at all), but the G711 side still receive glitchy/robotic sound.

I don't know what can be made, but i think we're not far from the solution. Please let me know if i can give you any information/trace to help fixing this.

Thank you

rfuchs commented 4 years ago

A pcap dump of the iLBC payload (that doesn't decode properly) would be helpful.

StellaTeam commented 4 years ago

dbg-ilbc.pcap.zip

Here is the pcap of all SIP dialog and RTP exchanges. Playing the sound on wireshark confirms the problem is real (and not a misbehavior on any phones).

Thank you Richard

rfuchs commented 4 years ago

Ok, so iLBC seems to be special in that the decoder needs to know the incoming ptime ahead of time. Fix is coming.

rfuchs commented 4 years ago

Ok I've updated the git branch, see commit 7e90442. Please try and report back.

StellaTeam commented 4 years ago

It works like a charm

Thank you very much @rfuchs for your quick and great job!

StellaTeam commented 4 years ago

@rfuchs I don't know if I should open another issue, as i discovered a quite related problem.

We discovered with this issue, transcoder is unable to guess which mode is in use, so it MUST be specified. Unfortunately, some manufacturers don't always specify ilbc mode, and so, the sound will be randomly choppy (depends on the devices default mode matching codec defaults or not)

We asked one of our manufacturer (PATTON) to get a fix, but this problem may occur later with other devices.

Couldn't rtpengine respectively try to :

I attached a example of scenario showing the problem.

Thank you

ilbc-codec-issues.txt

rfuchs commented 4 years ago

The mode should actually be taken from the ptime. In fact I wasn't aware of the mode= fmtp used by iLBC, so currently that is ignored by rtpengine (and also not set on outgoing). I'll add support for that, plus some extra log messages to see which mode rtpengine sets. Then we can look further.

StellaTeam commented 4 years ago

I'm not sure about the requirement to use ptime. It makes sense not to use mode=20 if ptime=30, and vice versa, but according to what i saw on devices, ptime is not mandatory.. So, if nor mode nor ptime is not specified by the sender, the receiver should choose and specify its choice on reply... or reject the call...

I don't know if you see what i mean...

For now, i saw that PATTON wasn't specifying ILBC mode in all cases, but i saw they allow user to force, or not, the ptime parameter to be send. So, i suppose it is better that proxies manage poorly behaving devices by either adapt themselves to what they have (ptime if present) or forcing devices to use their default preference or, in last resort, rejecting the calls if unable to decide...

What do you think?

rfuchs commented 4 years ago

Updated the branch/commit yet again (a4c80eb). This adds support for the iLBC fmtp mode= option, both inbound and outbound. It also adds dynamic decoder mode switching, so if a packet is received that doesn't match the current decoding mode, the decoder is automatically reset to the new mode.

For transcoding to iLBC, I would suggest specifying the full format, e.g. transcode=iLBC/8000/1///mode=30 ptime=30

StellaTeam commented 4 years ago

Thank you for fix patch, but no more luck, sound is still robotized. I tried to force ptime and mode to 30 (only mode supported by PATTON), and set the other device (GRANDSTREAM) to 30 too, without success. I tried to let the negociation to work automatically, not better...

I attached traces of the two modes.

Please let me know how i can help.

ilbc-issue-2.zip

StellaTeam commented 4 years ago

Just for you to know. I suspected 30 to be the default mode, and i just get confirmed about this. During my tests, i also tried to change your code defaults but it didn't seem to change anything to our current problem.

The mode parameter for ilbc is only required when the mode is 20 for ilbc 
15.2. A missing mode parameter must be treated as mode=30. 
RFC 3952 chapter 5: “Mapping To SDP Parameters” has an example for this
rfuchs commented 4 years ago

Ok, so first of all my apologies, the last commit had a booboo in it. It actually had the 20-ms and 30-ms modes reversed, so it actually made things worse. Updated commit e1a5aa40 has been pushed.

I've run your last pcaps through rtpengine's internal decoding engine and all the iLBC streams now decode properly, with one exception.

This is respectively SSRC 0x0025f958 and 0x00267888 from your pcaps. These are coming from the device 192.168.2.201 (ports 6068 and 6070 respectively), with payload type 109. On closer inspection, it looks like this device is getting the codec completely wrong. It starts sending the stream as PCMA with 160 bytes payload in each packet. It then switches the payload type to 109 (iLBC) but continues sending packets with 160 bytes payload. In other words, it continues to send PCMA but tagged as iLBC. Obviously this cannot be decoded properly. I confirmed this by running the raw data through ffmpeg directly, which also fails.

This is the same device that advertises iLBC as primary payload type, but without specifying the fmtp mode and with a ptime of 20. But this would still work if it wasn't for the fact that it's not actually sending iLBC.

So at this point, I don't think rtpengine can do anything about this. (Also I can't totally follow the call flow in these pcaps as there seem to be two distinct calls going on, perhaps with a PBX in between? But that shouldn't really matter.)

StellaTeam commented 4 years ago

@rfuchs Thanks for your great job.

As previously mentioned, as i also discovered it, RFC tells about iLBC to default to 30ms mode. So, i think, according to my understanding of your code, that is not the best to use 20ms mode, and so, it would probably better to code 

if (!mode) {
        mode = 30;
        ilog(LOG_WARNING, "No iLBC %s mode specified, setting to 30 ms", direction);
    }

in lib/codeclib.c instead of 

if (!mode) {
        mode = 20;
        ilog(LOG_WARNING, "No iLBC %s mode specified, setting to 20 ms", direction);
    }

Don't you think so?

rfuchs commented 4 years ago

This isn't really the default, but rather a fallback if neither a valid mode nor a valid ptime has been found. The actual default is in the codec definition: .default_fmtp = "mode=30"

Does this fallback ever get triggered in your use cases?

Also I haven't found the RFC reference that specifies a default of 30 ms mode.

StellaTeam commented 4 years ago

I well understood it was a fallback, and so, that's just a detail, nothing really important.

I just read the RFC PATTON told me about, and, even if it doesn't tell "mode 30 is default", it means the same

https://tools.ietf.org/html/rfc3952#section-5 

The resulting mode used by both
   parties SHALL be the lower of the bandwidth modes in the offer and
   answer.

as mode=30 is always the lower bandwidth consuming mode.

RFC also tells about not to use ptime to guess the mode, but when implementations are bad, we have no choice, so you did well :)

I didn't test your last code, i can't tell you if it triggers your fallback code. PATTON just told me their datasheets are wrong, and their DSP only support iLBC for SIP to SIP mode, that's a shame as it was the main reason of this issue.

RTPEngine has been improved, that's the most important ;)

rfuchs commented 4 years ago

That part of the RFC is actually not supported yet as there's no internal negotiation between the encoder and the decoder. So you might end up with incoming 20 ms frames and outgoing 30 ms, or vice versa. This will be implemented at a later point.

I just did a quick test and the default 30 ms mode seems to be applied just fine in both forward and backward transcoding directions.