On Mon, 18 Mar 2019, Richard F via ffmpeg-user wrote:
On 18/03/2019 20:25, Moritz Barsnick wrote:
On Mon, Mar 18, 2019 at 19:40:41 +, FFmpeg user discussions wrote:
I think the patch here: https://patchwork.ffmpeg.org/patch/12047 has
introduced a limit to the length of plain ASCII text t
On 18/03/2019 20:25, Moritz Barsnick wrote:
> On Mon, Mar 18, 2019 at 19:40:41 +, FFmpeg user discussions wrote:
>> I think the patch here: https://patchwork.ffmpeg.org/patch/12047 has
>> introduced a limit to the length of plain ASCII text that can be written
>> into mpegts metadata fields. I'
On Mon, Mar 18, 2019 at 19:40:41 +, FFmpeg user discussions wrote:
> I think the patch here: https://patchwork.ffmpeg.org/patch/12047 has
> introduced a limit to the length of plain ASCII text that can be written
> into mpegts metadata fields. I'm seeing ffmpeg exit when trying to write
> a str
I think the patch here: https://patchwork.ffmpeg.org/patch/12047 has
introduced a limit to the length of plain ASCII text that can be written
into mpegts metadata fields. I'm seeing ffmpeg exit when trying to write
a string of more than ~150 characters with "Too long service or provider
name".
Is
To further make clear,
I understand and acknowledge that HTTP uses TCP, of course. My desired
behavior is simply to encapsulate the TCP packets with HTTP formatting and
send with POST/PUT headers to server. The HTTP encapsulation is essential
for my use case.
I am able to make connection just fi
Thanks Moritz,
I tried to replicate your command, however, I am still only seeing TCP
packets (rather than HTTP packets) in my Wireshark output.
To be thorough, I have included my FFmpeg version commands for comparison.
The full commands I am running can be seen below :
From Client:
`ffmpeg -r
