Hello, thanks for your information, so, I have to resolve 2 problems to achieve my objective.
First, the stream reception, I have variable delays for the .ts segment downloads, and the stream copy appear not to be the solution, it seems transcoding could be, or I'am thinking in download the stream and generate chunks of files (.ts or mp4) continuously and differ the stream play through the IP QAM. The second problem is the UDP protocol, I have no choice to select TCP to send the stream, so I need to generate a constant bit rate with UDP. I prefer to focus in this last problem, now I downloaded a sample video in mp4, and want to generate a constant bit rate through the IP QAM, without transcoding. So this is my ffmpeg command, and output, I don't know if I'am configuring correctly the bitrate & burst_bits params, because still I see video faltering . Thanks for your suggestions! ffmpeg -re -i VfE_html5.mp4 -c copy -f mpegts -mpegts_pmt_start_pid 66 -streamid 1:71 -streamid 0:70 -flush_packets 0 'udp:// 224.1.1.1:1234?pkt_size=1316?bitrate=600000&burst_bits=600000' ffmpeg version 3.1 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 4.9.2 (Raspbian 4.9.2-10) configuration: --enable-gpl --enable-postproc --enable-swscale --enable-avfilter --enable-libmp3lame --enable-libvorbis --enable-libtheora --enable-libx264 --enable-libspeex --enable-pthreads --enable-libopenjpeg --enable-libfaac --enable-nonfree libavutil 55. 27.100 / 55. 27.100 libavcodec 57. 48.101 / 57. 48.101 libavformat 57. 40.101 / 57. 40.101 libavdevice 57. 0.101 / 57. 0.101 libavfilter 6. 46.102 / 6. 46.102 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 1.100 / 2. 1.100 libpostproc 54. 0.100 / 54. 0.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VfE_html5.mp4': Metadata: major_brand : mp42 minor_version : 1 compatible_brands: mp42avc1 creation_time : 2011-03-16 10:41:51 Duration: 00:01:00.08, start: 0.000000, bitrate: 699 kb/s Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt709), 640x360, 633 kb/s, 24.04 fps, 24.04 tbr, 2500 tbn, 5k tbc (default) Metadata: creation_time : 2011-03-16 10:41:52 handler_name : Apple Video Media Handler Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 62 kb/s (default) Metadata: creation_time : 2011-03-16 10:41:53 handler_name : Apple Sound Media Handler [mpegts @ 0x2386480] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. Last message repeated 1 times Output #0, mpegts, to 'udp:// 224.1.1.1:1234?pkt_size=1316?bitrate=600000&burst_bits=600000': Metadata: major_brand : mp42 minor_version : 1 compatible_brands: mp42avc1 encoder : Lavf57.40.101 Stream #0:0(eng): Video: h264 (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt709), 640x360, q=2-31, 633 kb/s, 24.04 fps, 24.04 tbr, 90k tbn, 2500 tbc (default) Metadata: creation_time : 2011-03-16 10:41:52 handler_name : Apple Video Media Handler Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, 62 kb/s (default) Metadata: creation_time : 2011-03-16 10:41:53 handler_name : Apple Sound Media Handler Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (copy) Press [q] to stop, [?] for help frame= 40 fps= 25 q=-1.0 Lsize= 125kB time=00:00:01.62 bitrate= 631.3kbits/s speed=1.02x video:98kB audio:12kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 13.763228% On Wed, Jul 20, 2016 at 6:12 PM, kv pham <pkv.str...@gmail.com> wrote: > 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" <iasimo...@outlook.com> a écrit > : > > > > From: anacelia.sa...@gmail.com > > > Date: Wed, 20 Jul 2016 09:38:06 -0300 > > > To: ffmpeg-user@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 <reube...@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@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > > > To unsubscribe, visit link above, or email > > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".