[FFmpeg-user] HTTP playlist stream copy to an IP QAM modulator
kv pham
pkv.stream at gmail.com
Thu Jul 21 21:26:58 EEST 2016
Your binary doesnt seem to be the latest so no patch of the jitter.
Secondly I use the following trick to use tcp. At the target I start a
second ffmpeg instance which will listen at the tcp sent from the encoder
and relay to the real client in udp. This removes the issues of lost
packets since the udp source and client are on the same server.
ffmpeg -i tcp://IP:port?listen -vcodec copy -acodec copy -f mpegts
udp://localhost:port?pkt_size=1316
If your program has more streams than video and stereo audio you might need
to specify them with -map.
Le 21 juil. 2016 7:44 PM, "Anacelia Sarlo" <anacelia.sarlo at gmail.com> a
écrit :
> 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.stream at 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" <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".
> > _______________________________________________
> > 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".
> >
> _______________________________________________
> 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".
More information about the ffmpeg-user
mailing list