> FFmpeg is trying to remux this file and breaking its compliance then.
> It's the same problem VLC has had for years (and why multicat was
> written).
No, I don't think FFmpeg is not trying to remux the file. I use FFmpeg to
transcode and mux the file as a single program transport stream and out
On 19 November 2015 at 16:15, Zach Swena wrote:
>> How have you confirmed MPEG-TS compliance?
>
> While not completely definitive, I looked at it with a transport stream
> analyser and tested it at our TV station. At the TV station stream the
> file from our server through a remultiplexer that as
> How have you confirmed MPEG-TS compliance?
While not completely definitive, I looked at it with a transport stream
analyser and tested it at our TV station. At the TV station stream the
file from our server through a remultiplexer that assembles the multi
program transport stream with our vario
On 19 November 2015 at 12:00, Pavel Meshkov wrote:
> FYI, our awful hack looks like almost working except sometimes effective
> bitrate lost for 1-2 seconds, then spike and then returns to normal (it can
> be once after 15 minutes or after more than 4 hours before this issue).
>
> Also there is a
FYI, our awful hack looks like almost working except sometimes effective
bitrate lost for 1-2 seconds, then spike and then returns to normal (it
can be once after 15 minutes or after more than 4 hours before this issue).
Also there is a question: how it supposed schedule to send packets of
131
> Why is there a udp stream output option then? Are you trying to say that
> this isn't a bug because FFmpeg isn't supposed to be able to stream? I am
> using FFmpeg mpeg2video as the encoder and multiplexing with mpegts. The
> data FFmpeg produces is fine, it just doesn't send it quite right.
On Wed, Nov 18, 2015 at 08:54:13PM -0800, Zach Swena wrote:
[...]
> Is udp.c supposed to work with any other multiplexer then
> mpegts? In my experience it doesn't.
udp can work with any muxer that does not require seeking (if all
packets are received at the receiver end)
if OTOH some packets ar
> A proper ts remuxer is quite a different beast to what FFmpeg is
> designed to do. As much as people try it can't be hacked into the
> FFmpeg paradigm which is largely based around converting static files
> of fixed codecs/resolutions in a nonrealtime environment from A to B.
Why is there a udp
> Of course if the user copies a video stream that isn't complaint there will
> be problems if the decoder requires that. The issue here is two fold.
> First, the current udp transmission model can cause problems with
> networking equipment because of it's bursty nature. Second, FFmpeg can
> make
> Because FFmpeg again cannot know a priori whether the input signal is
> fully VBV compliant for use within MPEGTS.
> An RTMP feed is an example of a feed which certainly isn't and so
> FFmpeg has to make some numbers up in order to make a valid TS.
> Such guessing might work in the file world but
On 18 November 2015 at 19:28, Zach Swena wrote:
> Are you referring to this seperate applciation?
>
> https://github.com/mmalecki/multicat/blob/master/trunk/README
>
> While using that makes sense for Pavel's application, why should FFmpeg
> produce a problematic UDP stream in the first place? Fo
Hi,
On Wed, Nov 18, 2015 at 9:28 PM, Zach Swena wrote:
> Are you referring to this seperate applciation?
>
> https://github.com/mmalecki/multicat/blob/master/trunk/README
>
Probably what was meant was
http://www.videolan.org/projects/multicat.html , but that might be a
git svn clone of it.
>
>
Are you referring to this seperate applciation?
https://github.com/mmalecki/multicat/blob/master/trunk/README
While using that makes sense for Pavel's application, why should FFmpeg
produce a problematic UDP stream in the first place? For applications like
I need that involve encoding the stream
> Only for strict CBR streams which FFmpeg cannot know a priori. That's
> why the only correct way is to index the stream as it's received and
> play out at a smooth rate like multicat does.
I am not sure what you are referencing with regards to multicat. Is this
an output option? Smooth output
Yea, how it is supposed to happen isn't complicated. To be of any help, I
have to wrap my mind around how FFmpeg currently times the output stream.
That mechanism currently does not produce as stable of a transmission rate
as multiplexer and decoder hardware requires. Since there is a bounty
avai
> i suggest you read the mpeg specs, they detail when things should be
> sent down to each byte IIRC
> also IIRC its not that complicated, more like timestamp + bytepos/rate
Only for strict CBR streams which FFmpeg cannot know a priori. That's
why the only correct way is to index the stream as it'
On Tue, Nov 17, 2015 at 03:06:27PM -0800, Zach Swena wrote:
> Hi Pavel,
>
> I can confirm that there is a problem with the UDP packet engine in
> FFmpeg. FFmpeg has excessive jitter in it's UDP streaming output to the
> point where hardware decoders can't handle it. My solution was to buffer
> t
Hi Pavel,
I can confirm that there is a problem with the UDP packet engine in
FFmpeg. FFmpeg has excessive jitter in it's UDP streaming output to the
point where hardware decoders can't handle it. My solution was to buffer
to disk and have my own program read and send the datagrams via a very
ti
Good day.
We still need this feature. Can someone implement above functionality on
bounty base (up to $2000)?
12.11.2015 12:28, Pavel Meshkov пишет:
Thanks for explanation.
We will try to rewrite it with new knowledge.
I need your suggestion.
We are try to send constant udp stream from rtmp l
Thanks for explanation.
We will try to rewrite it with new knowledge.
I need your suggestion.
We are try to send constant udp stream from rtmp live stream with only
repack it.
I found "mpegts_write_packet_internal" function
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mpegtsenc.c#L140
On 11 November 2015 at 22:41, Kieran Kunhya wrote:
>
> On 11 Nov 2015 7:08 p.m., "Pavel Meshkov" wrote:
>>
>> Trying to reattach patch
>>
>> 11.11.2015 22:01, Pavel Meshkov пишет:
>>>
>>> We added UDP output constant bitrate functionality.
>>> Please review patch.
>>>
>>> P.S.: It's first patch w
On 11 Nov 2015 7:08 p.m., "Pavel Meshkov" wrote:
>
> Trying to reattach patch
>
> 11.11.2015 22:01, Pavel Meshkov пишет:
>>
>> We added UDP output constant bitrate functionality.
>> Please review patch.
>>
>> P.S.: It's first patch we send. Please notify me if something made wrong.
This an awful
Trying to reattach patch
11.11.2015 22:01, Pavel Meshkov пишет:
We added UDP output constant bitrate functionality.
Please review patch.
P.S.: It's first patch we send. Please notify me if something made wrong.
___
ffmpeg-devel mailing list
ffmpeg-dev
We added UDP output constant bitrate functionality.
Please review patch.
P.S.: It's first patch we send. Please notify me if something made wrong.
udp-cbr-single.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:
24 matches
Mail list logo
