Description

Here is the first issue. I have 2 ffmpeg processes, the first one should send the a/v (aac+h264) to the localhost:port using udp, and the 2nd ffmpeg process should pick it up and just save to the .ts file.

I'm sure the network is not an issue here :) and also, I've monitored cpu usage (on a dual core) and it didn't go over 40% at any time.

Also, when I record a live stream this way for a very long time (like 12 hours or more) the audio and video get totally async, meaning audio is progressively advancing before the video and after like 3-4 hours of recording, the drift is around 10 seconds and will get even bigger for the longer period of the recording.

I can send you samples of .ts files, only I'll need to record for that long, so you can see that it really happens.

Other issues are related to remuxing from .ts to .flv (also with h264+aac), but I'll see to create new tickets for that.

Well, I didn't try just recording to .ts file for that long, more rational way was to stream to an udp port because that way I could duplicate the data and watch it, while it is being saved to a file.

Anyway, for the absf, I don't remember now where exactly did I pick up that option (was it in ffmpeg channel or google), I just know that without it, when I play the udp stream in VLC, then the audio is a lot more quirky, skipping up/down-sampling and stuff... And since there is no official documentation on that filter ( ​http://ffmpeg.org/ffmpeg.html#aac_005fadtstoasc ), I didn't have chance to read about its real intended usage, so it might be the reason of the async behavior.

Can You give me one working example (default or something) of using mpegts (h264+aac) over udp, just to test it, because I've tried so many different combinations and variations I can't even remember now and none of them gave the smooth and clean playback without async (I'm talking about 100/100 LAN network). What could be the simplest way to start such a stream?

The problem still exists.
That message tells that the timestamps are somehow wrong, I guess. Sometimes I can see the image freezes for a fraction of a second and the image goes distorted just like a wrong keyframe was used for all the subsequent delta frames, but it gets back to normal after a couple of seconds.

I apologize, it seems that this error is related to a slow hardware (??) although I'm not sure why, because the cpu usage never gets over 30-40%, but they say its related to a slow decoder/cpu or something like that, so this bug report can be closed without further examination, I guess.