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" <[email protected]> a écrit : > > From: [email protected] > > Date: Wed, 20 Jul 2016 09:38:06 -0300 > > To: [email protected] > > 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 <[email protected]> > 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
