[FFmpeg-user] rtp_mpegts metadata copying and pmt_pid/pcr_pid setting
Felipe W Damasio
felipewd at taghos.com.br
Wed Jun 12 16:27:20 EEST 2019
Hi Moritz,
----------------------------------------
From: "Moritz Barsnick" <barsnick at gmx.net>
Sent: Wednesday, June 12, 2019 5:59 AM
Oh, indeed, that was me. That proposed patch is broken though. I
crafted a proper one - which should be correct - and forwarded it to
the development list upstream:
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-July/231816.html
https://patchwork.ffmpeg.org/patch/9566/
But this patch was never merged, or even reviewed.
-
Right, I saw that too...but since there was no comment, I decided to check
if there was a reason nobody merged the code (or if just was a matter of
showing interest in the fix to get things moving :-)).
-
I can't pitch in on this one. I don't know whether the mpegts sub-muxer
of rtp_mpegts parses mpegts's options, and whether these can be passed
on to rtp. I experimented a bit, but have a hard time interpreting the
results. Someone else should comment.
-
Right, according to my testing, it doesn't. as soon as data flow through
rtp_mpegts muxer, everything is back to default values.
What I've been trying to use in the meantime is something like this:
ffmpeg -i rtp://<multicast input>:<port> -map_metadata 0 -movflags
use_metadata_tags -c copy -f mpegts -mpegts_flags
"resend_headers+initial_discontinuity" udp://127.0.0.1:12345
And then using the multicat tool to trying to transform UDP packets to RTP
ones
multicat -p 68 -u 127.0.0.1:12345 <multicast output>:<port>
Then we could get potentially the benefits from the mpegts muxer and all
those options, and have someone ele generate the RTP packets. But this is
not working great currently. Still testing.
Cheers,
Felipe Damasio
More information about the ffmpeg-user
mailing list