Thanks Moritz,
Appreciate your help in debugging what I initially thought was a muxing
issue.
Do you have any thoughts on my above post in terms of what could be causing
the data to not be received by my FFmpeg server (receiving)?
Please advise. Any thoughts or suggestions would be greatly
On Wed, Mar 20, 2019 at 13:03:11 -0400, Glenn W wrote:
> > I'm totally convinced that if you use ffmpeg the way you are doing, you
> use HTTP only.
>
> So are you thinking all those TCP [PSH, ACK] packets are contained within a
> given HTTP POST?
Yes.
> If you look at the first few packets, I
For reference, here are the results of my latest attempt to send chunked
data over HTTP to cloud endpoint behind HTTP Nginx Load Balancer:
See earlier posts for details on configuration and other errors which I
have resolved.
TLDR; Connection is being made, and server (receiving side) is getting
> btw, did you set client_max_body_size in nginx.conf ? something like
100M :-)
Yes, see:
"Now, setting my nginx configuration to not check for the body size by
setting max to 0 in the ingress configuration template, I tried again: "
I set to zero so as to forgo the body size check
btw, did you set client_max_body_size in nginx.conf ? something like
100M :-)
On Wed, Mar 20, 2019 at 6:03 PM Glenn W wrote:
> Thanks Moritz,
>
> > File share host. ;-)
>
> So true. Please see below link for more full example log from my local
> tests:
>
>
>
Thanks Moritz,
> File share host. ;-)
So true. Please see below link for more full example log from my local
tests:
https://drive.google.com/file/d/1HMS64eBDpTRlFwVarz8G75IffHzgqvCV/view?usp=sharing
> I would guess that this trace was started *after* the HTTP
connection was established.
This
remarque: ppl who send ismv via http to unified streaming servers
(apache/nginx) just put http url as output, it works.
On Wed, Mar 20, 2019 at 1:20 PM Ted Park wrote:
> > In my trace which I had analyzed as a proof of concept, HTTP was
> > perfectly recognized. I had used port , while my
> In my trace which I had analyzed as a proof of concept, HTTP was
> perfectly recognized. I had used port , while my Wireshark's HTTP
> protocol seems to be configured to
> "80,3128,3132,5985,8080,8088,11371,1900,2869,2710". So Wireshark should
> be smart enough...
You must be right, the
On Wed, Mar 20, 2019 at 06:56:38 -0400, Ted Park wrote:
> IIRC, if you do not use heuristic sub-dissectors first, you will have
> to add port 5558 to http protocol settings. Don't see any headers
> though… Maybe you can check the logs on the receiving end?
In my trace which I had analyzed as a
> Wireshark does not even recognize this POST as
> HTTP protocol.
IIRC, if you do not use heuristic sub-dissectors first, you will have to add
port 5558 to http protocol settings. Don't see any headers though… Maybe you
can check the logs on the receiving end?
On Tue, Mar 19, 2019 at 21:05:19 -0400, Glenn W wrote:
> Please see the new attached PCAP file with a sample of the correct
> Wireshark output bound to localhost. (had to gzip this one since it was
> pretty big)
Unlikle the relatively tiny logs, you could upload such binaries to a
file sharer of
On Tue, Mar 19, 2019 at 22:49:32 +0100, Carl Eugen Hoyos wrote:
> 2019-03-19 18:46 GMT+01:00, Glenn W :
>
> > Please see the below full console output
>
> Unfortunately not;-(
Too bad it'ss in an external link (which tends to disappear after
weeks).
> Anyway, this was certainly transmitted via
Carl,
> Anyway, this was certainly transmitted via http.
What is your evidence for this claim? Where do you see any HTTP headers? I
do not see any in my Wireshark output nor do I see any indication of HTTP
protocol being used.
> The more important question is if there is an issue: Segmentation
Hello friends,
I reach this talk because I try also to use FFMpeg as transcoder for live
streams over HTTP , but I can't find the right way .
with this command ffmpeg is sending data to a server that is listening on
port and dir 5558/video, but I can't understand what kind of configuration
web
2019-03-19 18:46 GMT+01:00, Glenn W :
> Please see the below full console output
Unfortunately not;-(
Anyway, this was certainly transmitted via http.
The more important question is if there is an issue:
> Segmentation fault: 11
This normally indicates a (important) bug.
Carl Eugen
Hi Glenn,
On Mon, Mar 18, 2019 at 14:27:43 -0400, wolfe.t.glenn wrote:
> Is there some 3rd party library I might be missing here?
I don't think so.
Can you please
- post the actual complete console output (not just the version info),
- send me a PCAP file as captured with Wireshark?
Thanks,
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
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
On Thu, Mar 14, 2019 at 17:22:54 -0400, Glenn W wrote:
> So far, while testing on my local network I am using these commands, which
> works, but uses TCP rather than HTTP. I need to use HTTP only.
That's a bit of an ambiguous statement. TCP is layer 3, HTTP is layer
7, and uses TCP underneath.
>
19 matches
Mail list logo
