QSTranscode / Tickets / #13 Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs

babgvant - 2013-12-15

status: open --> accepted

assigned_to: babgvant
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-15

My guess is that the problem is that currently QSTranscode generates timestamps with the assumption that the source isn't missing packets. I'll have a look.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Dave - 2013-12-15
  
  Yes it's very likely my TS files have missing packets. My cable line has errors sometimes. But the src TS plays fine on PC. Whereas the converted file has bad av sync. Ideally qstranscode could handle these scenarios.
  
  On Dec 15, 2013, at 1:43 AM, "babgvant" babgvant@users.sf.net wrote:
  
  My guess is that the problem is that currently QSTranscode generates timestamps with the assumption that the source isn't missing packets. I'll have a look.
  
  [tickets:#13] Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs
  
  Status: accepted
  Created: Sat Dec 14, 2013 11:25 PM UTC by Dave
  Last Updated: Sat Dec 14, 2013 11:25 PM UTC
  Owner: babgvant
  
  I'm not sure why, but some of my clear QAM recordings result in slowly drifting AV sync. Perhaps there are some errors in the transport stream. Other channels sync fine over an hour. Here is a short blurb where the AV sync is off by around 500ms right away.
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/qstranscode/tickets/13/
  
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave - 2013-12-20

1.0.23: Unfortunately, we've stepped backwards here: AV sync is off by a full second or so, even on Windows 7 playback. It's not even close. Also, LookAhead just locks up, so I had to move to CBR.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-20

Please create a separate ticket for LookAhead (make sure you're on latest drivers first though).

Can you provide a longer sample TS? It doesn't have to be here, a download service (dropbox, skydrive, gdrive, etc) works too.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave - 2013-12-20

The minimum show size I have is 30 min, which is about 3.5gigs. Previous clips were just me randomly recording a station for 10 sec. Probably not OK for me to upload a full recorded broadcast (copyright), but short clips should be OK. Let me know the length you need, and I'll see what I can do.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-20

Just a couple minutes would be fine as long as it encapsulates the problem in a reproducible way.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave - 2013-12-20

The existing clips I already uploaded don't exhibit this AV sync issue? I found it was off from the start, even on PC now.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-20

The cooking one was perfect w/ 1.0.2.2 (didn't test w/ 1.0.2.3), the other one is too short for me to tell for sure.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave - 2013-12-20

Here is a short clip of about 15 seconds with a talking head. The AV sync from QSTranscode'd output (to MP4) is off immediately on PC playback via Media Player Classic.

PassThrough_AAC_Stereo.xml

news.ts

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave - 2013-12-20

BTW, this clip does not lock up LookAhead. Looks like only long clips do that.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-20

Thanks

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-28

1024 should fix this issue. I had to make significant changes to the way input timestamps are handled* so it's possible that other issues were introduced. I'm traveling at the moment so I didn't test it with many files (only have a couple clips with me). So if you could help out with some testing I'd appreciate it. Also, I think I figured out why Ffmpeg 2+ was leaking memory, so it's back in as well.

Normally this would be pretty straightforward, but because QSTranscode supports EDL I can't use the timestamps from the file directly so I have to generate my own. For this file it looks like the video packets at the beginning are corrupt so audio starts well before there are matching video frames. I wasn't able to figure out how to safely drop the audio, so QSTranscode will process both but try to use the original timestamps to adjust the generated ones. Hopefully your results match mine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Dave - 2013-12-30

The news.ts file (talking head) attached to this ticket is still way off sync with 1024. Appears to be no change from 1023 actually.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-30

What player/SW are you using? I was using WMP to test it.

It might be a driver thing. My laptop is pretty old so it doesn't get many new drivers, but I'll install the latest and see if it behaves differently.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Dave - 2013-12-30
  
  I use MPC-HC to play the files. Nvidia 570 GPU. Sandy bridge 2600k CPU.
  
  On Dec 30, 2013, at 7:18 AM, "babgvant" babgvant@users.sf.net wrote:
  
  What player/SW are you using? I was using WMP to test it.
  
  It might be a driver thing. My laptop is pretty old so it doesn't get many new drivers, but I'll install the latest and see if it behaves differently.
  
  [tickets:#13] Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs
  
  Status: accepted
  Created: Sat Dec 14, 2013 11:25 PM UTC by Dave
  Last Updated: Mon Dec 30, 2013 04:21 AM UTC
  Owner: babgvant
  
  I'm not sure why, but some of my clear QAM recordings result in slowly drifting AV sync. Perhaps there are some errors in the transport stream. Other channels sync fine over an hour. Here is a short blurb where the AV sync is off by around 500ms right away.
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/qstranscode/tickets/13/
  
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-30

You're using a more modern system to do the transcoding? The MSDK's behavior can vary b/w driver versions, so that might be why we're seeing different results. I updated the drivers on my SNB laptop and the A/V is working the same as before (good). I might be able to scare up an IVB system to run it on and see if the timestamps are different.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Dave - 2013-12-30
  
  I transcode on an i3 Haswell NUC. I cannot transcode on the SNB as it has a MB with discrete video card. The NUC is my 'server' (transcode, record), while the SNB is my 'client' (playback).
  
  On Dec 30, 2013, at 8:10 AM, "babgvant" babgvant@users.sf.net wrote:
  
  You're using a more modern system to do the transcoding? The MSDK's behavior can vary b/w driver versions, so that might be why we're seeing different results. I updated the drivers on my SNB laptop and the A/V is working the same as before (good). I might be able to scare up an IVB system to run it on and see if the timestamps are different.
  
  [tickets:#13] Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs
  
  Status: accepted
  Created: Sat Dec 14, 2013 11:25 PM UTC by Dave
  Last Updated: Mon Dec 30, 2013 03:18 PM UTC
  Owner: babgvant
  
  I'm not sure why, but some of my clear QAM recordings result in slowly drifting AV sync. Perhaps there are some errors in the transport stream. Other channels sync fine over an hour. Here is a short blurb where the AV sync is off by around 500ms right away.
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/qstranscode/tickets/13/
  
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2013-12-31

There was a behavioral difference b/w SNB & IVB/HSW. 1025 takes this into account and is a little smarter (I think) with how it handles DTS/PTS. Hopefully you can reproduce and it doesn't break anything :).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Dave - 2014-01-01
  
  Didn't have time to try SNB. However, on both HSW and a Chromebook, the AV
  is now in sync for the news.ts file. Unfortunately, the frame rate appears
  halved now. So it's not really playable this way either.
  
  On Mon, Dec 30, 2013 at 7:07 PM, babgvant babgvant@users.sf.net wrote:
  
  There was a behavioral difference b/w SNB & IVB/HSW. 1025 takes this into
  account and is a little smarter (I think) with how it handles DTS/PTS.
  Hopefully you can reproduce and it doesn't break anything :).
  
  [tickets:#13] http://sourceforge.net/p/qstranscode/tickets/13/
  Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs*
  
  Status: accepted
  
  Created: Sat Dec 14, 2013 11:25 PM UTC by Dave
  Last Updated: Mon Dec 30, 2013 04:10 PM UTC
  Owner: babgvant
  
  I'm not sure why, but some of my clear QAM recordings result in slowly
  drifting AV sync. Perhaps there are some errors in the transport stream.
  Other channels sync fine over an hour. Here is a short blurb where the AV
  sync is off by around 500ms right away.
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/qstranscode/tickets/13/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2014-01-02

I can't think of a reason why the framerate would have changed. IIRC, this clip is interlaced so the default behavior is to DI to 30p.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Dave - 2014-01-02
  
  Surprised myself. That's why I tried playing back directly on the Haswell NUC server. Looks like 15fps or less. Probably it is still 30fps, but the PTSs are doubled up or something along that line.
  
  Perhaps it's an ffmpeg thing. Showed same low frame rate playback on a Haswell chromebook.
  
  Dave.
  
  On Jan 1, 2014, at 4:39 PM, "babgvant" babgvant@users.sf.net wrote:
  
  I can't think of a reason why the framerate would have changed. IIRC, this clip is interlaced so the default behavior is to DI to 30p.
  
  [tickets:#13] Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs
  
  Status: accepted
  Created: Sat Dec 14, 2013 11:25 PM UTC by Dave
  Last Updated: Tue Dec 31, 2013 03:07 AM UTC
  Owner: babgvant
  
  I'm not sure why, but some of my clear QAM recordings result in slowly drifting AV sync. Perhaps there are some errors in the transport stream. Other channels sync fine over an hour. Here is a short blurb where the AV sync is off by around 500ms right away.
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/qstranscode/tickets/13/
  
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2014-01-04

Try 1.0.2.6. 29.97 interlaced content should really be rendered (or in this case encoded) @59.94 when deinterlaced so the default behavior has been changed to reflect that.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Dave - 2014-01-05
  
  The ZIP file for 1026 is corrupt.
  
  Dave.
  
  On Sat, Jan 4, 2014 at 3:45 PM, babgvant babgvant@users.sf.net wrote:
  
  Try 1.0.2.6. 29.97 interlaced content should really be rendered (or in
  this case encoded) @59.94 when deinterlaced so the default behavior has
  been changed to reflect that.
  
  [tickets:#13] http://sourceforge.net/p/qstranscode/tickets/13/
  Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs*
  
  Status: accepted
  
  Created: Sat Dec 14, 2013 11:25 PM UTC by Dave
  Last Updated: Thu Jan 02, 2014 12:39 AM UTC
  Owner: babgvant
  
  I'm not sure why, but some of my clear QAM recordings result in slowly
  drifting AV sync. Perhaps there are some errors in the transport stream.
  Other channels sync fine over an hour. Here is a short blurb where the AV
  sync is off by around 500ms right away.
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/qstranscode/tickets/13/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

babgvant - 2014-01-05

Uploaded again.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs

Transcode files with Intel QuickSync.

Milestone

Searches

Help

#13 Resulting H.264 AV Sync drifts with certain MPEG2TS stream inputs

Discussion