This project has moved and is read-only. For the latest updates, please go here.

Audio isnt synced with video?

May 16, 2013 at 8:20 PM
I'm trying to play this streaming source:
http://dmiLiveDubaiOne.http.internapcdn.net/dmiLiveDubaiOne/dubaiOneLive130503.m3u8

but I'm the audio isnt synced with the video, can you help me to fix it.
Coordinator
May 17, 2013 at 12:00 AM
Edited May 17, 2013 at 12:00 AM
There does seem to be a slight A/V sync problem. Are you sure this isn't happening on other players? VLC seemed to be doing the same thing.

I'm not saying that there isn't a problem with the code, but if there is a fixed offset, then you could try doing something like this to compensate:

Change TsMediaParser.cs (around line 200) from:
            lock (_mediaStreamsLock)
            {
                _timestampOffsetHandlers.Add(ts => localStreamBuffer.TimestampOffset = ts);
            }
to this:
            lock (_mediaStreamsLock)
            {
                _timestampOffsetHandlers.Add(ts =>
                                             {
                                                 localStreamBuffer.TimestampOffset = ts;

                                                 if (streamType.Contents == TsStreamType.StreamContents.Video)
                                                     localStreamBuffer.TimestampOffset += TimeSpan.FromMilliseconds(500);
                                             });
            }
Obviously, 500ms would be too large, but one should hopefully be able to find a constant that works. If you need to move things in the other direction, changing the "TsStreamType.StreamContents.Video" into "TsStreamType.StreamContents.Audio" should be safer than subtracting an offset.

Also, there are some constants in BufferingManager that are probably too small for this stream. If you change the first two constants into something like this, then there should be less "Buffering":
        const int BufferSizeMaximum = 4096 * 1024;
        const int BufferSizeStopBuffering = 2048 * 1024;
May 17, 2013 at 1:13 AM
Thanks for answering my questions.

I tried this file here and it worked fine:
http://osmfhls.kutu.ru/

The issue is that the offset is keep getting larger. so setting the offset wouldn't help. I tried different files and all of them work but this one.
Coordinator
May 17, 2013 at 3:10 AM
Could you give it a try with those BufferingManager changes to see it that makes a difference for you? I had it running for 45 minutes or so on an HTC Titan (with OS 7.8) with no change in A/V sync over that period, but I had changed the buffering constants as soon as I first tried the stream because it was clearly not behaving properly (going back into buffering right after it was done buffering).

Also, what are you testing on? WP7 or WP8? Emulator or real device? A build for WP8-only or one of the WP7 builds?

Thanks.
Coordinator
May 17, 2013 at 7:36 AM
I tried viewing the stream again and had a great deal of trouble. The A/V was completely out-of-sync, the code was reporting invalid packets, and Fiddler2 was reporting some protocol violations (the Content-Length header was sometimes larger than the actual content length when downloading .ts segments).
May 17, 2013 at 2:29 PM
I'm testing on both emulator and Lumia 920, I tried to increase the buffer, and play with the offset. I'm getting the same random results. Probably theres something wrong with the streaming sources, but I think other players handle them.

Any other suggestions?
Coordinator
May 17, 2013 at 7:16 PM
Edited May 17, 2013 at 7:17 PM
Well, the partial .ts segments could explain how things are getting out of sync.

Hypothesis 1

The reader is trying to buffer things faster than the server expects and is sometimes reading .ts segments faster than the CDN is populating them.

I would expect something more dramatic than a truncation, but okay...

Hypothesis 2

The reader is falling too far behind the server and as a result, the files are getting removed from the server while they are being read.

Again: truncation?

Hypothesis 3

...?

Suggestions

  1. The reader could be modified to report an error when Content-Length doesn't match the file length.
  2. The reader could be modified to insist on reading Content-Length bytes (when there is a Content-Length header), triggering the existing range-reading retry code when it doesn't match.
  3. The processing pipeline could be enhanced to pass metainformation along with the raw .ts data. That way, a Seek() could be triggered when there is a known discontinuity in the data stream.
  4. The stream selection code could be modified to try the lowest bandwidth stream:
subProgram = program.SubPrograms.OrderBy(sp => sp.Bandwidth).FirstOrDefault();
  1. Monitor the network activity of a working player and compare.
  2. Finish switching the network code over to HttpClient to see if it behaves any differently (this is being done to better support async/await as well as to provide better cancellation support). It may behave differently.
  3. If we are running behind, then it might be worth trying to change which entry in the playlist is read first. Right now, it is starting with the first entry. Picking the second or third might work better for this stream (I have already changed this behavior multiple times...).

Note

I'll at least give #2 a try this weekend. #3 and #6 are on my to-do list, but involve more time than I might have available this weekend (particularly #3).
Coordinator
May 20, 2013 at 9:50 AM
I took another look at this and it appears that the CDN is sometimes truncating files (I'm inclined to believe hypothesis 2). I've started making some changes to enable a seek to be queued up along with the A/V samples, but this is a fairly significant change to the code. I did check in a few other things from my development tree to get them out of the way, which has probably destabilized the tree to some degree (d649a58c2412 is probably the safest thing to use right now), but I don't expect that any of those changes will help with this particular problem.

If you get a chance, could you give the lower bandwidth stream a try? It seemed to help avoid the problem here. If I could get a confirmation, then that would suggest we are at least headed in the right direction.

Thanks.
May 23, 2013 at 10:24 PM
I tried that, didnt work. It helped in the first 5 secs, but thats it. And I dont think they have lower bandwidth stream, because I'm getting the same quality...
Coordinator
May 23, 2013 at 11:41 PM
I made some progress towards queueing a seek when data has been lost. The code is now detecting this condition, but the bit to do something constructive about it isn't working yet. I think I'll be able to get to a point where I can check something in this coming weekend. That should fix the problem you are seeing.

IIRC, there were two alternatives at different bandwidths in the main .m3u8 file (put the URL in a web browser or, from a UNIX-like environment grab it with curl or fetch).
Coordinator
Aug 6, 2013 at 2:35 AM
I haven't forgotten about this, but the fix requires touching pretty much every part of the pipeline. The same changes are required to resolve a number of other problems, so it will get fixed, but I'm not sure when I'll get a chance (I need several consecutive days without distractions, but in the last few months that has not been possible).