[FFmpeg-user] mpegts metadata not set

Zak ffmpeg-user-email at m.allo.ws
Wed Jun 27 23:05:48 EEST 2018

On 2018-06-27 at 10:28 AM EDT, Christian Knoefel | Ilm-Provider wrote:
> Hello,
> i will remux an ts:
> ffmpeg -re -i rtmp://live.net/rtmp/live -vcodec mpeg2video -s 720x576 -r 
> 25 -flags cgop+ilme -sc_threshold 1000000000 -b:v 5M -minrate:v 5M 
> -maxrate:v 5M -bufsize:v 3.5M -acodec mp2 -ac 2 -b:a 192k -metadata 
> "service_provider=Some Provider" -metadata "service_name=Some Channel 
> Name" -f rtp_mpegts rtp://
> Stream mapping:
>    Stream #0:1 -> #0:0 (h264 (native) -> mpeg2video (native))
>    Stream #0:0 -> #0:1 (aac (native) -> mp2 (native))
> Press [q] to stop, [?] for help
> Output #0, rtp_mpegts, to 'rtp://':
>    Metadata:
>      service_provider: Some Provider
>      service_name    : Some Channel Name
>      encoder         : Lavf58.17.100
>      Stream #0:0: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 64:45 
> DAR 16:9], q=2-31, 5000 kb/s, 25 fps, 90k tbn, 25 tbc
>      Metadata:
>        encoder         : Lavc58.20.103 mpeg2video
>      Side data:
>        cpb: bitrate max/min/avg: 5000000/5000000/5000000 buffer size: 
> 3500000 vbv_delay: -1
>      Stream #0:1: Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s
>      Metadata:
>        encoder         : Lavc58.20.103 mp2
> wit ffplay looks like this:
> Input #0, rtp, from 'rtp://':   0KB sq=    0B f=0/0
>    Duration: N/A, start: 91.443144, bitrate: 5192 kb/s
>    Program 1
>      Metadata:
>        service_name    : Service01
>        service_provider: FFmpeg
>      Stream #0:1: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), 
> yuv420p(tv, bottom first), 720x576 [SAR 64:45 DAR 16:9], 5000 kb/s, 25 
> fps, 25 tbr, 90k tbn, 50 tbc
>      Stream #0:0: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, 
> s16p, 192 kb/s
> Why metadate are not set?
> it is the newest 64bit windows build...
> thanks for your suggestion...
> Christian

Hello Christian,

I suspect the root problem is this:

1. When FFmpeg (the first call, for transcoding/remuxing), when FFmpeg 
creates the MPEG TS, where is it putting the "metadata"? The MPEG 
transport stream protocol is SUPER old, I would be surprised if there 
were less than a dozen ways to store metadata.

2. When FFplay tries to play back the MPEG TS stream, where is it 
reading the metadata? Quite likely not the same place. I have no idea.

Here are some suggestions:

1. Consider what application you actually want to use for playback, 
because they will support different types of metadata. VLC, for example, 
supports VERY LITTLE metadata, which annoys me at times. Even if VLC 
reads the format for the metadata, it will never show you certain keys, 
it only shows you a few of the keys. For instance, "Get Info" on VLC 
usually shows a key "Year" for streaming video, but I know the video has 
"original air date" (year, month, and day), "copyright date", and 
possibly other things. And then "Year" is "2018", and that's just not 
right. That was the encoding year, probably. FFprobe can actually be 
helpful determining what is going on with things like this if you have 
no idea (because I have no idea how metadata is stored in MPEG transport 

2. MAYBE try putting the -metadata arguments after the "-f rtp_mpegts" 
argument. Sometimes (often) the order of arguments matters in FFmpeg. I 
have no idea if that is the case here. Maybe it "processed" -metadata 
early, when it thought you were going to use a MKV file as the output, 
and it got that metadata all ready for a MKV file. Then it saw "-f 
rtp_mpegts" and it threw away the things that go in MKV but not in MPEG 
TS, and then re-generated some metadata for MPEG TS. This is a wild 
guess, I would try it. The order of arguments mostly matters when the 
arguments apply to specific streams (like audio versus video versus the 
audio commentary). You can specify streams with (colon)(digit), such as 
-c:v:2, but some arguments do not support that syntax (as far as I 
know), so you need to put the argument in the group with that whole 
stream, and the location tells it to go with "2".

3. Before somebody else asks, you might want to include the whole uncut 
console output, including the "banner" printed by FFmpeg and FFplay that 
says the configuration options when it was compiled, and so on. I 
suspect it is not going to be hugely relevant, but you never know. You 
did say it is the latest Windows build, but these Mailman archives will 
be around for a long time, and what if you think you are using the 
latest build because you installed it, but at the hour of typing the 
command, your PATH variable decided to use an older version of FFmpeg 
that was lying around somewhere on your hard drive? (There is a nice 
xkcd comic about having tons of versions of the Python interpreter on 
one machine, because computers get messy.)

Good luck,


More information about the ffmpeg-user mailing list