[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