[FFmpeg-user] HTTP playlist stream copy to an IP QAM modulator

[kv pham]

Mpegts udp suffers from excessive jitter.
This has been fixed only four weeks ago.
Check that your ffmpeg is recent enough.
Cf https://trac.ffmpeg.org/ticket/4155

Also try the option flush_packets 0 to ensure consistent packet size.

Le 20 juil. 2016 10:27 PM, "Isaac Asimov" <iasimovsp at outlook.com> a écrit :

> > From: anacelia.sarlo at gmail.com
> > Date: Wed, 20 Jul 2016 09:38:06 -0300
> > To: ffmpeg-user at ffmpeg.org
> > Subject: Re: [FFmpeg-user] HTTP playlist stream copy to an IP QAM
> modulator
> >
> > Reuben, thanks to answer. I did 2 tests :
> > 1. I received the stream with VLC and I have a similar problem like with
> > the IP QAM.
> > 2. Transcode the stream and the video its ok.
> >
> > But my doubt is, if I receive the "stream copy" with ffplay, it runs
> > perfect!, so
> > it seems the response to my problem is, the way ffplay process/recover
> the
> > time base.
> >
> > If I enable a debug it looks like every time ffmpeg make an http request
> > for
> > the playlist, there is a delay until receive it, and seems at this point
> > the video freeze, and then continue.
> > Thanks for another suggestion.
> > Ana
> >
> > On Wed, Jul 20, 2016 at 12:56 AM, Reuben Martin <reuben.m at gmail.com>
> wrote:
> >
> > > On Tuesday, July 19, 2016 10:16:03 PM CDT Anacelia Sarlo wrote:
> > > > ffmpeg -re -y -i $stream  -c copy -f mpegts -map 0:0 -map 0:1
> > > > -mpegts_pmt_start_pid 66 -streamid 1:71 -streamid 0:70 udp://
> > > > 192.168.1.108:1234?pkt_size=1316
> > > >
> > > > When I watch the stream from the cable network,  the audio is OK but
> the
> > > > video looks sometimes faltering and other times too fast, and out of
> > > sync.
> > > > But when I received this same output with ffplay it runs OK.
> > > > It seems there is a problem with the time base, I did many testings
> with
> > > > (genpts, copyts, etc)  with no good results.
> > >
> > > You might try and see what happens if you re-encode it rather than
> copying
> > > the
> > > media streams. Thing is with copying the stream you pass on any flaws
> that
> > > might be able to be corrected by ffmpeg, but are not as gracefully
> dealt
> > > with
> > > by other implementations.
> > >
> > > At least that might help narrow the problem down a bit and determine
> if the
> > > problem is with the origional source, or with ffmpeg.
> > >
> > > It would be nice to have a bit-stream filter to re-write time stamps
> when
> > > doing a stream copy, but sadly no such filter exists yet.
> > >
> > > -Reuben
>
> I don't know in cable networks but in DVB-T (terrestrial) there are "Null
> packets" in MPEG-TS mux, with PID 0x1FFF which target it's achieve a
> constant bit rate, will null data. AFAIK ffmpeg don't generate this kind of
> packets because it's unneeded in IPTV, that should be task of IP QAM
> firmware.
>
> By the other side, MPEG-TS can use PTS and PCR info in each Packetized
> elementary stream (e.g. in each video frame) to achieve sync, it's easy
> play a video correctly without that info (and maybe that is the reason
> ffplay play ok), but most MPEG-TS players need PCR and PTS fields to avoid
> errors playing.
>
>
>
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".