Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: how to force inclusion of periodic ID3 tags using lame API? (Read 4342 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

how to force inclusion of periodic ID3 tags using lame API?

My application is streaming RTP/MP3 content to a client like VLC using the lame API. I am having problems getting this to work and so I have a few questions about using the lame API. I am using wireshark to monitor my RTP/MP3  traffic.

I am using the various ID3 API routines like id3tag_set_title() to set content information. In the very first RTP pkt, which contains the first encoded MP3 frame, I can see the ID3 tag all correct, then the padding bytes, then the first MP3 frame header. As expected, the ID3 tag is not found in any subsequent frames.

Since my application is streaming, I would think it useful to include the ID3 periodically in the stream, perhaps every 60 seconds or so. That way if a client joins the stream after the first frames have passed, it will still be able to get some content information about the stream.

Q1:  Is periodic inclusion of ID3 tags a violation of the MP3 standard/usage?  that is, is it only for a single inclusion in MP3 files and should not be used in streaming?
Q2: If not, what lame API routine should I periodically call to do this?

I can only observe an MP3 header on the very first frame. I cannot seem to find any further MP3 headers in my pkts. At this point, I have only done a visual inspection, so I am assuming they are actually there. But there is NEVER an MP3 frame header at the start of any encoded frame (which is the start of the RTP payload which is what I get from the lame_encode_buffer() routine). So the encoded data returned from lame_encode_buffer() never seems to be on actual MP3 frame boundaries.

Q3: Am I correct to interpret this to be the proper/usual/correct operation of the bit resevoir functionality and not my screwing up the packetazation of the encoded MP3 stream?

Thanks,

-Andres


how to force inclusion of periodic ID3 tags using lame API?

Reply #2
Thank you [JAZ] for your reply and the link. It appears that it will be very useful.

-Andres

how to force inclusion of periodic ID3 tags using lame API?

Reply #3
Andres, did you take a look at LAME's RTP code, you can find it in the 'frontend' folder?

front end of the encoding loop:
frontend/mp3rtp.c

socket communication functions:
frontend/rtp.c

how to force inclusion of periodic ID3 tags using lame API?

Reply #4
Robert, thank you for your reply and suggestions.

Yes, I have looked at that code. It was useful but I still have questions. It is slightly different from my application, in that it's source is a file and my application is real time live streaming. But never the less, it was still very useful to see that code.

I am using VLC as the receiving client, and I cannot get it to process my RTP/MP3 pkts correctly. When my code streams RTP/PCM to VLC it processes the stream correctly so that is my testing process. However, when I stream RTP/MP3 to VLC, it gets all screwed up. Consequently, I keep thinking that I must be either encoding the MP3 wrong or packetizing that stream to RTP wrong.

-Andres