| Message ID | d2d9d254-24dc-4b57-b98d-fe27f5cad307@nativewaves.com |
|---|---|
| State | New |
| Headers | show |
| Series | WebRTC sub-second live streaming support | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl:
> Whitespaces after semicolon breaks some servers
Which servers? If the spec allows whitespace then the onus is on them
to fix their implementations.
/Tomas
On Tue, 14 Nov 2023 at 16:47, Tomas Härdin <git@haerdin.se> wrote: > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > Whitespaces after semicolon breaks some servers > > Which servers? If the spec allows whitespace then the onus is on them > to fix their implementations. > > /Tomas > Poor Tomas, you are not versed in SDP witchcraft where a single character breaks dozens of devices but fixes dozens of others. Kieran
Le tiistaina 14. marraskuuta 2023, 17.47.07 EET Tomas Härdin a écrit : > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > Whitespaces after semicolon breaks some servers > > Which servers? If the spec allows whitespace then the onus is on them > to fix their implementations. I couldn't find any note to the effect that white spaces are allowed to separate format parameters in RFC4566, but maybe I didn't look hard enough. I think that most implementations just happen to ignore white-spaces, either *because* some broken implementations like FFmpeg do send them, or just by implementation accident.
tis 2023-11-14 klockan 18:51 +0200 skrev Rémi Denis-Courmont: > Le tiistaina 14. marraskuuta 2023, 17.47.07 EET Tomas Härdin a écrit > : > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > > Whitespaces after semicolon breaks some servers > > > > Which servers? If the spec allows whitespace then the onus is on > > them > > to fix their implementations. > > I couldn't find any note to the effect that white spaces are allowed > to separate > format parameters in RFC4566, but maybe I didn't look hard enough. > > I think that most implementations just happen to ignore white-spaces, > either > *because* some broken implementations like FFmpeg do send them, or > just by > implementation accident. It wouldn't be the first time FFmpeg did something wrong Anyway I'm not formally against this patch, especially since it's not something I maintain :) /Tomas
tis 2023-11-14 klockan 17:14 +0100 skrev Kieran Kunhya: > On Tue, 14 Nov 2023 at 16:47, Tomas Härdin <git@haerdin.se> wrote: > > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > > Whitespaces after semicolon breaks some servers > > > > Which servers? If the spec allows whitespace then the onus is on > > them > > to fix their implementations. > > > > /Tomas > > > > Poor Tomas, you are not versed in SDP witchcraft where a single > character > breaks dozens of devices but fixes dozens of others. I have in fact had some contact with SDP, much to my chagrin. This is also why we should be very strict with it, and be very clear what the spec says, and/or have the spec changed to reflect reality. With MXF, being strict has already paid dividends. /Tomas
On Tue, 14 Nov 2023, 21:54 Tomas Härdin, <git@haerdin.se> wrote: > tis 2023-11-14 klockan 17:14 +0100 skrev Kieran Kunhya: > > On Tue, 14 Nov 2023 at 16:47, Tomas Härdin <git@haerdin.se> wrote: > > > > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > > > Whitespaces after semicolon breaks some servers > > > > > > Which servers? If the spec allows whitespace then the onus is on > > > them > > > to fix their implementations. > > > > > > /Tomas > > > > > > > Poor Tomas, you are not versed in SDP witchcraft where a single > > character > > breaks dozens of devices but fixes dozens of others. > > I have in fact had some contact with SDP, much to my chagrin. This is > also why we should be very strict with it, and be very clear what the > spec says, and/or have the spec changed to reflect reality. With MXF, > being strict has already paid dividends. > > /Tomas > Not comparable IMO, these are embedded IoT devices that will never be fixed. I have spent months of my life debugging a single character issue in SDP. I kid you not. Kieran >
Le mar. 14 nov. 2023 à 09:47, Tomas Härdin <git@haerdin.se> a écrit : > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > Whitespaces after semicolon breaks some servers > > Which servers? If the spec allows whitespace then the onus is on them > to fix their implementations. The logic could be inverted: if the specs allow for both but a majority of users do not accept white space, it would make sense to change the implementation to maximize compatibility. > /Tomas > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
diff --git a/libavformat/sdp.c b/libavformat/sdp.c index 68889362906..5ab017b1ba5 100644 --- a/libavformat/sdp.c +++ b/libavformat/sdp.c @@ -159,8 +159,8 @@ static int extradata2psets(AVFormatContext *s, const AVCodecParameters *par, { char *psets, *p; const uint8_t *r; - static const char pset_string[] = "; sprop-parameter-sets="; - static const char profile_string[] = "; profile-level-id="; + static const char pset_string[] = ";sprop-parameter-sets="; + static const char profile_string[] = ";profile-level-id="; uint8_t *extradata = par->extradata; int extradata_size = par->extradata_size; uint8_t *tmpbuf = NULL;
Whitespaces after semicolon breaks some servers Signed-off-by: Michael Riedl <michael.riedl@nativewaves.com> --- libavformat/sdp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)