Ok, thanks, I will check wowza / player properties, and will check again
PTS fields of the packets.
On Fri, Jul 19, 2013 at 7:23 PM, Oleg wrote:
> If you're sure, then trouble exists in player, because it should do
> synchronizing of audio and video, and for this thing it needs PTS values.
> Ot
Player should use PTS value anyway for correct and smooth playback. Are you
sure that you're filling PTS correct?
19.07.2013, в 19:20, Gyula Hatalyák написал(а):
> Hi,
>
> I am streaming out packets with RTMP output format to Wowza media server.
> I have a packet buffer as the input of the RT
I am quite sure.
BTW: If I omit the "-re" flag from the command line, it also runs and
finishes as quick as it can - processing and sending the packets regardless
PTS/DTS. On the server side (Wowza) there is no slow-down to make it
real-time.
It is strange for me.
On Fri, Jul 19, 2013 at 6:54 PM,
Hello,
I have a similar problem. I need to stream some videos through udp/mpegts.
Without flow control memory grows continuously.
I solved comparing stream time with absolute time a making some Sleep(...)
to slow down packet sending.
I would like to know if a more elegant solution is available.
t
If you're sure, then trouble exists in player, because it should do
synchronizing of audio and video, and for this thing it needs PTS values.
Otherwise player can't play smoothly. If you don't have these values playback
will not be synchronized as CPU burst\network trouble or OS lag would sudden
Hello Massimo,
I'm using PTS values and 1 second timer and have no problems at all.
Also it's possible to sleep in thread by (cur_pts - prev_pts) value to get the
most accurate timing, but of course it consumes more CPU.
But these methods works only for streams where packets ordered by PTS. If
Hi,
I am streaming out packets with RTMP output format to Wowza media server.
I have a packet buffer as the input of the RTMP muxer.
I can send the packets faster than their duration - by
av_interleaved_write_frame calls.
I send all the packets in the buffer until it is empty, and then wait for
ne
Julian Diego Herrera Braga writes:
> > Please provide a complete backtrace including
> > disassembly and register dump, as explained on
> > http://ffmpeg.org/bugreports.html
> >
> > No way to reproduce the problem with the
> > ffmpeg executable?
> >
> Can I run the ffmpeg executable on an iOS dev
On 19/07/2013 14:45, Carl Eugen Hoyos wrote:
Julian Diego Herrera Braga writes:
I've updated the project to link against ffmpeg-2.0 and
now the issue seems to be worse. FFmpeg now crashes
more often during a seek operation. This is the new
backtrace:
* thread #14: tid = 0x3303, 0x001d133c ast
Julian Diego Herrera Braga writes:
> I've updated the project to link against ffmpeg-2.0 and
> now the issue seems to be worse. FFmpeg now crashes
> more often during a seek operation. This is the new
> backtrace:
>
> * thread #14: tid = 0x3303, 0x001d133c astra
> `ff_put_pixels16_neon, stop
On 18/07/2013 12:34, Carl Eugen Hoyos wrote:
Julian Herrera writes:
frame #2: 0x002dd6e6 astra`mpeg_decode_slice(s=0x0f9eaa00,
buf=0x03985a14) + 7854 at mpeg12.c:1813
This looks outdated.
Is the problem also reproducible with current
git head?
Carl Eugen
I've updated the project to
On date Wednesday 2013-07-17 11:57:54 +0200, Francesco Damato encoded:
> Hi,
>
> I am an engineering student and i am writing a C program to encode
> to mpeg2 video read from file, send it to a stream and then decode
> it.
>
> I saw the example decoding_encoding.c that generates a video from
> du
Am 19.07.2013 02:26, schrieb James Board:
*From:* Thomas
*To:* "This list is about using libavcodec, libavformat, libavutil,
libavdevice and libavfilter."
*Sent:* Thursday, July 18, 2013 8:55 AM
*Subject:* Re: [Libav-u
13 matches
Mail list logo
