[FFmpeg-devel] [PATCH] avformat/mpegts: initialize max_packet_size when sub-demuxer

[FFmpeg-devel] [PATCH] avformat/mpegts: initialize max_packet_size when sub-demuxer

[Gyan Doshi]

bca30570d2 added a user option to set max_packet_size replacing
a hardcoded value. This had a side-effect of leaving the field
set to 0 when packet demuxing is carried out from another demuxer
using avpriv functions, which could lead to demux failure.

Hardcoded max_packet_size inside avpriv_mpegts_parse_open to
2048000 to avoid this. Value chosen to be 10x that of default value
to accommodate large payloads.
---
 libavformat/mpegts.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index da15223b8a..e23f596490 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -3377,6 +3377,7 @@ MpegTSContext *avpriv_mpegts_parse_open(AVFormatContext *s)
         return NULL;
     /* no stream case, currently used by RTP */
     ts->raw_packet_size = TS_PACKET_SIZE;
+    ts->max_packet_size = 2048000;
     ts->stream = s;
     ts->auto_guess = 1;
 
-- 
2.34.1

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: initialize max_packet_size when sub-demuxer

[Marton Balint]

On Sat, 5 Feb 2022, Gyan Doshi wrote:

> bca30570d2 added a user option to set max_packet_size replacing
> a hardcoded value. This had a side-effect of leaving the field
> set to 0 when packet demuxing is carried out from another demuxer
> using avpriv functions, which could lead to demux failure.
>
> Hardcoded max_packet_size inside avpriv_mpegts_parse_open to
> 2048000 to avoid this. Value chosen to be 10x that of default value
> to accommodate large payloads.

I don't understand why the default is different from the normal mpegts 
case. Large payloads can happen there as well, and previously it was 
assumed that splitting is OK, because it will be parsed anyway.

Regards,
Marton


> ---
> libavformat/mpegts.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index da15223b8a..e23f596490 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -3377,6 +3377,7 @@ MpegTSContext *avpriv_mpegts_parse_open(AVFormatContext *s)
>         return NULL;
>     /* no stream case, currently used by RTP */
>     ts->raw_packet_size = TS_PACKET_SIZE;
> +    ts->max_packet_size = 2048000;
>     ts->stream = s;
>     ts->auto_guess = 1;
>
> -- 
> 2.34.1
>
> _______________________________________________
> 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".
>
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: initialize max_packet_size when sub-demuxer

[Gyan Doshi]

On 2022-02-07 03:59 am, Marton Balint wrote:
>
>
> On Sat, 5 Feb 2022, Gyan Doshi wrote:
>
>> bca30570d2 added a user option to set max_packet_size replacing
>> a hardcoded value. This had a side-effect of leaving the field
>> set to 0 when packet demuxing is carried out from another demuxer
>> using avpriv functions, which could lead to demux failure.
>>
>> Hardcoded max_packet_size inside avpriv_mpegts_parse_open to
>> 2048000 to avoid this. Value chosen to be 10x that of default value
>> to accommodate large payloads.
>
> I don't understand why the default is different from the normal mpegts 
> case. Large payloads can happen there as well, and previously it was 
> assumed that splitting is OK, because it will be parsed anyway.
The option was added because MPEG-TS allows any codec to be carried as a 
private stream and when demuxing that, the parser isn't inserted, even 
when forcing a decoder, hence the need to not have split packets. In 
this case, the user can't tune the value, so I went with an expansive one.

Regards,
Gyan
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: initialize max_packet_size when sub-demuxer

[Gyan Doshi]

On 2022-02-07 09:34 am, Gyan Doshi wrote:
>
>
> On 2022-02-07 03:59 am, Marton Balint wrote:
>>
>>
>> On Sat, 5 Feb 2022, Gyan Doshi wrote:
>>
>>> bca30570d2 added a user option to set max_packet_size replacing
>>> a hardcoded value. This had a side-effect of leaving the field
>>> set to 0 when packet demuxing is carried out from another demuxer
>>> using avpriv functions, which could lead to demux failure.
>>>
>>> Hardcoded max_packet_size inside avpriv_mpegts_parse_open to
>>> 2048000 to avoid this. Value chosen to be 10x that of default value
>>> to accommodate large payloads.
>>
>> I don't understand why the default is different from the normal 
>> mpegts case. Large payloads can happen there as well, and previously 
>> it was assumed that splitting is OK, because it will be parsed anyway.
> The option was added because MPEG-TS allows any codec to be carried as 
> a private stream and when demuxing that, the parser isn't inserted, 
> even when forcing a decoder, hence the need to not have split packets. 
> In this case, the user can't tune the value, so I went with an 
> expansive one.

Plan to push tomorrow.

Regards,
Gyan
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: initialize max_packet_size when sub-demuxer

[Gyan Doshi]

On 2022-02-08 04:33 pm, Gyan Doshi wrote:
>
>
> On 2022-02-07 09:34 am, Gyan Doshi wrote:
>>
>>
>> On 2022-02-07 03:59 am, Marton Balint wrote:
>>>
>>>
>>> On Sat, 5 Feb 2022, Gyan Doshi wrote:
>>>
>>>> bca30570d2 added a user option to set max_packet_size replacing
>>>> a hardcoded value. This had a side-effect of leaving the field
>>>> set to 0 when packet demuxing is carried out from another demuxer
>>>> using avpriv functions, which could lead to demux failure.
>>>>
>>>> Hardcoded max_packet_size inside avpriv_mpegts_parse_open to
>>>> 2048000 to avoid this. Value chosen to be 10x that of default value
>>>> to accommodate large payloads.
>>>
>>> I don't understand why the default is different from the normal 
>>> mpegts case. Large payloads can happen there as well, and previously 
>>> it was assumed that splitting is OK, because it will be parsed anyway.
>> The option was added because MPEG-TS allows any codec to be carried 
>> as a private stream and when demuxing that, the parser isn't 
>> inserted, even when forcing a decoder, hence the need to not have 
>> split packets. In this case, the user can't tune the value, so I went 
>> with an expansive one.
>
> Plan to push tomorrow.

Pushed as b6bb6b9f22ff519644b16dcc71a4b92ee3979c1b

Regards,
Gyan
_______________________________________________
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".