mythreplex --fix_sync option broken for PAL

[anonymous]

When using mytharchive to create a DVD of a PAL mpeg2 file, the audio is approximately .5s out of sync from the video.

If I remove the new --fix_sync option from mythburn.py when it calls mythreplex, the audio is in sync.

I have tried this with PAL mpeg files from PVR-250, DVB and created from a MiniDV recording using kino. All had the same issue.

I tried it with an NTSC mpeg file and --fix_sync did not cause a problem.

MythTV Library API version: 0.20.20060828-3 Source code version: 12641M

Allen

[myth@…]

Forgot to add my email address.....

[paulh]

If only it was that easy :-) Unfortunately I'm in the UK and therefor also use PAL and I see the exact opposite. Without the --fix_sync the audio gets out of sync after each cut point!! I've tried many times with both PVR-250 and DVB-t recordings to reproduce this problem but it always works fine for me.

If the audio is consistently 0.5 secs out throughout a file then it would be possible to fix it simply by passing an audio sync offset to mplex to compensate for it but we would need to know how big the offset needs to be for each file and also which files need the offset and which don't.

Do you run your recordings through mythtranscode --mpeg2 before you try to use mytharchive to create a DVD. There is a suspicion that using mythtranscode --mpeg2 twice on the same file causes problems but I cannot confirm this.

[paulh]

(In [12891]) Add the stream start times to the streaminfo.xml generated by mytharchivehelper. Maybe used later for a fix to the audio sync problem some people are having with DVDs created with MythArchive?.

Refs #3146.

[paulh]

If someone who can reproduce this update to current SVN, create a DVD with a single file on it that has this problem (there's no need to burn the DVD just creating the file system will do) then email me the progress.log. I may also need the more detailed mythburn.log later but the progress log will do for now.

I'd also like to know what the source of the recording was PVR250, DVB etc, whether the recording had been processed by mythtranscode --mpeg2 before the DVD creation process and roughly by how much the audio is out of sync (using the internal myth player is good for this because you can adjust the sync offset from the OSD).

[mythtv@…]

Darn.... I was getting a consistent behavior (PAL vs. NTSC). It is never that easy though :)

In my case, I have set mytharchive to not transcode. The DVB files I used had been transcoded earlier to remove commercials (I did this before I used mytharchive). The mpeg2 files from kino had never been transcoded and had this problem.

From memory, progress.log showed a lot of audio frames (?) dropped at the beginning (about 0.5s worth), then at the end, it added a lot of blank frames.

Unfortunately, I don't have an easy way to upgrade to the current SVN at the moment. If it would help, I could get a very small sample mpeg2 file.

[paulh]

Replying to mythtv@hain-veilchen.de:

Unfortunately, I don't have an easy way to upgrade to the current SVN at the moment. If it would help, I could get a very small sample mpeg2 file.

Yes, If you can make a small sample file available it would help.

[anonymous]

I've put a one minute mpeg along with resulting iso and log files at: wget ​http://www.hain-veilchen.de/download/example.tar.gz

I notice in the logs that only 2 frames are "removed" at the start and then 2 are "added" at the end. On longer recordings, a lot more are lost, then re-added, even though the sync error is about the same.

Let me know if there is anything else I can do to help.

Cheers,

Allen

[anonymous]

Forgot to mention: This example is from a PVR-250, untranscoded.

Hmmmm... Just taking a closer look at this and the sync issue looks much smaller in the example I sent. Probably around 0.1s. I'm not sure if this is because the clip is short or because the recording is from the PVR-250 and I usually record of the DVB card.

I'll try and take a closer look and see if I can narrow it down.

Just had another thought: The logs show 2 frames dropped in this example (.08s). On my other recordings, I was noticing around 10 frames dropped (0.4s) This seems to match the offset I'm seeing. However, the sync error is not progressive. It is consistent through the whole recording.

I'll get a log file from a longer recording.

[paulh]

(In [12951]) This adds an option to apply a sync offset when remuxing the video and audio streams together using mplex.

For the moment you have to enable it by setting the variable 'useSyncOffset' to 'True' at the top of the mythburn.py script.

I'm not sure what the best way is to calculate exactly what the offset should be for all files, I currently use the video and audio start times as reported by the avcodec library to workout what the sync offset was prior to splitting the file and use the same offset when remuxing the streams.

I really need somebody who can see the sync problem to give it a try to see if I'm on the right track or not. The audio sync difference is just too subtle for me to see, I guess some people are more sensitive to this than others :-)

Refs #3146.

[anonymous]

It looks like this will work on my version by just replacing the mythburn.py script. I'll give it a try and let you know.

Cheers,

Allen

[paulh]

Replying to anonymous:

It looks like this will work on my version by just replacing the mythburn.py script. I'll give it a try and let you know.

Cheers,

Allen

Unfortunately not. You will also need the change in [12891] which adds the stream start times to the streaminfo.xml file.

[anonymous]

Thanks for the info. I'll see if I have enough to re-build mytharchivehelper tonight.

Cheers,

Allen

[anonymous]

Hmmm.... I naively thought the myth source would be sitting on my knoppmyth install. I only have an analog modem at home, so I'll have to get the tar balls and bring them home on usb stick. If I understand correctly, I just need to configure/make (not install) mythtv then copy the mytharchivehelper bin file over.

This might take a while as it is a first for me.

Allen

[paulh]

(In [13313]) Merge [12891] and [12951] from trunk into the fixes branch.

Adds an option to apply an audio sync offset when the video and audio streams are remuxed together using mplex.

I still haven't had any feed back on whether this improves things or not. Hopefully having it in the fixes branch will provide more feedback.

Refs #3146.

[anonymous]

Sorry, I haven't had a chance to test this. I tried to re-compile and ran into problems. I'm traveling on business for the next 6 weeks, but I hope to be able to give it a try again then.

Thanks,

Allen

[paulh]

I believe this particular cause of audio sync problems was fixed in [12891] and [12951] and merged into the fixes branch in [13313].

[mythtv@…]

Hi.... I just got back and was able to upgrade to Library API version: 0.20.20060828-4 Source code version: 13420

If I understand correctly, this should include changeset 13313. However, I still get a very big sync issue. When I remove the --fix_sync option, the problem goes away.

Am I correct that 13313 is included in 13420?

Allen