H.264 Audio/Video Sync Issues

[mxyzptlk]

I ended up at these forums looking for any solutions to the h.264 audio/video sync issues on the C Series. I only found a few others with the same problem, and only one response stating it wasn't a problem on the B Series. So I'm posting this to A.) Clarify what the problem is, B.) Offer some suggestions for what might help, and C.) Maybe spur someone's imagination to come up with a better solution. (There's not much about this going on at the Samsung website.)

The Problem
With the C Series, audio and video for files made with the h.264 codec tend to get out of sync. The audio starts to slide behind the video a bit. This doesn't always happen, but is more likely to occur after pausing the video and hitting play again, or more likely after rewinding/fast-forwarding. It makes watching the video near-impossible.

This only seems to occur with files made with h.264; xvid files don't lose sync. One response I saw here said that it wasn't an issue with mkv files (again on the B Series), but of course an h.264 video can be inside an mp4 or an mkv container. I'm not certain if it's specific to aac, ac3 and/or mp3 audio, but I think the problem is with the video codec.

I've followed the Samsung firmware updates, and none seem to address this. (My television won't even recognize the latest firmware updates from Sept, 2010, so I can't say if that would address the issue, but nothing in the firmware specifications says anything about audio/video sync problems.)

For what it's worth, I have a C530.

What Helps (Some)
After a lot of experimentation, I've found a few things that can help. But these are all temporary and only address the symptom per video; they don't fix the problem.

First, sometimes pausing the video for a while -- 30 seconds or more -- will allow things to catch up. I can't say for certain, but it seems hitting the actual pause button instead of the center button between the four arrows works better.

Sometimes messing with the skip back/skip ahead and then rewinding a bit will get things lined up again. Messy and only effective maybe half the time.

Under Sound in the Menu, there's an SPDIF option, and you can adjust audio delay in there. I've had the most luck setting it to .80; this doesn't seem to knock anything out of sync when a video is first played, and tends to keep things in sync more effectively.

But the most effective solution I've found is also the biggest pain in the neck; re-encode the file with two passes. This takes hours and is overkill, unless the file is one you need to see more than once and pause/rewind/fast-forward quite a bit (like if you're studying a film). That suggests to me that how the television is reading h.264 files, it isn't very forgiving.

Again, this doesn't seem to happen with xvid files in avi containers, but does happen with h.264 files in mp4 and mkv containers.

Thoughts? Is this something that firmware could address?

[erdem_ua]

Hi there...
Welcome to our forum.

I think you see another ones post too which is C530. Might be this is a C530 bug.

Do you contacted with Samsung about the issue? What they said about it?
Well, It's better to search your country consumer laws. You might receive some of your units price due the bug. At least it's true on here...

Anyway. You said that "problem doesn't seem to happen with xvid files in avi containers, but does happen with h.264 files in mp4 and mkv containers."
I feel I am the best person that you could find anywhere about the problem. Not due being SamyGO admin but a DivFix++ (#1 AVI repair program) and Meteorite MKV (Only MKV Fix program) programs author

MKV is far more complex container than AVI and MKV processing requires significant work power even on your PC. MKV has 2 main different format in it by different version of frame blocking. I don't want to enter the details but since they are just "container", you can transcode MKV file to AVI file without re-encoding... It will take nearly just copy time of file. You have better to test your same movies after AVI transcoding. Than we might to understand if the problem due MKV container or not.

And you can categorize movies, which ones has sync issue and which ones not. Than you can analyze the movie files with GSpot like program and compare the files. With it we could understand what the common parts of problematic videos like video/audio codecs, bitrate, encoding profile, channel count etc... This will give us better diagnostic of problem, than we could solve the issue. (Hey Samsung!, this is actually your FW problem! Please quit your meaningless signature requests on proposed custom SamyGO firmwares and just fix your *ss! )

[mxyzptlk]

Thanks man, good info here.

That's a good test -- transcoding an out-of-sync file to avi. I have a file right now that I've been experimenting with, and I'll try it on that one.

As for whether this is just a C530 issue, I don't think so -- I've seen other people in other forums have similar issues on a variety of C machines. I've also contacted Samsung, and the help desk claimed they didn't know about the problem. There's at least one question about it over at the Samsung support page, and that's mine.

(I should also note that the out-of-sync files play fine on my computers.)

No need to get into avi/mkv specifics -- I know enough to get by, and understand how an avi would require less processing power than an mp4 or mkv. But I guess that raises another question -- why would mp4 and mkv files that fell out of sync be fine after a two-pass re-encode? If it's a processing issue, does the two-pass re-encode just tidy things up enough inside the container to reduce the necessary processing power?

Something else I found (just last night) is a sound delay option inside the Service Menu > Config. That was set to 10. I moved it to 0, which seemed to help some, but didn't solve the problem. (I've messed with this issue for nearly two years, and the night I post here is the night I find that option... sheesh.)

That makes me wonder if there isn't a setting someplace within that Service Menu to make it read h.264 files more accurately. Could it be a graphics card issue? I can't find any info on it now, but I recall something about an nvidia card built into the television -- and if my laptop's Intel GM965 can handle the extra overhead of an mp4 or an mkv file, I'd think an nvidia card could.

By the way, I don't think I can get anything back on the TV because my warranty just ran out. The model I have was discontinued just when I bought it -- it's a 37" TV, and is the only one I could find that fits perfectly into an elevated nook built into the wall. So I already got a deal on it when I bought it, and didn't renew the warranty.

As for GSpot, I'm on a Linux box so I don't have that installed, but I have something that should give more than enough info. I wanted to post the specs of the wonky file in mkv format and the same file now working after being transcoded into avi, but the forum tells me it's too spammy and won't let me post.

[erdem_ua]

I don't think if transcode to AVI will fix the issue. I just say that because you think AVI format is free from that issue. But trying is easy and doesn't take much time. You have to be sure that is not "container" problem first...

Why 2 pass re-encode fix the issue? I don't know. Might be you choose avi format for resulting file .
I believe it is related with h264 encode profiles. Some high profiles are require high processing power. If TV's DSP not enough to solve that complex instructions, CPU might try to solve remaining and this could be the reason of slowness. With re-encode, you might just reduce / change profile of the video...

Again, please compare codec parameters with delaying and not delaying videos...

And I don't understand what you mean... Do you playing that video by TV processor or do you playing the video at your PC, via HDMI streaming?
I am talking if you are playing the video at your TV like playing from usb device... And external processors cannot accelerate TVs processes, at least with current technology level. Expect this in 10 years.

Here, consumer law defines that, if defect is not easily recognizable , there is no time limit. Even if warranty is out, producer needed to fix it under 30 day or accept to return TV. I think you have better to read consumer law at your country

I recently installed spam blocker to forum. You needed to post some (5) messages after sending links or all viagra spams over here and there

[mxyzptlk]

I'm sorry if I wasn't clear on a few things. I'll try again.

I don't think if transcode to AVI will fix the issue[...] Why 2 pass re-encode fix the issue? I don't know. Might be you choose avi format for resulting file .

So far, if I take an mp4 file or mkv file that gets out of sync and re-encode it exactly as it is but with two passes, it's fine. So the video remains in an mp4 or an mkv container; the audio/video bitrate is the same; the dimensions are the same; everything is the same except it's give two passes on the re-encode. This takes a long, time but it works.

Again, please compare codec parameters with delaying and not delaying videos...

I won't be able to post any specs here until I post some more messages, but the above should help some -- I can take two copies of the same file with all the same specs save for the two-pass re-encode, and one will stay in sync and the other won't. (That just makes me think there's something to be said for two-pass encoding when dealing with a container with a lot of overhead.)

And I don't understand what you mean... Do you playing that video by TV processor or do you playing the video at your PC, via HDMI streaming?

Okay, I guess I wasn't clear here. I'm talking about playing a video on the TV via USB. What I meant was the same file that gets out of sync on the television via USB never has any problems when I play it back on my computer.

So there doesn't seem to be anything wrong with the file itself, only its playback on the television. I only thought that the television should be more powerful than my 6-year-old laptop when it comes to playing back video.

I'll check into the consumer laws, but I'm also interested if this is a possible firmware issue or if there's some other way to address it; what I wouldn't want to do is to replace this television with another model that has the same problem, especially since they no longer make a 37' model.

I did transcode one file to avi, and I did not have any sync issues with it. This was a file made up of a few h.264 pieces that was originally muxed into an mkv container; I transcoded it to xvid/ac3 in an avi container and had no sync issues. So that's another bit of info.

One thing I'm going to try today, though, is using a more powerful external drive to hook up to the TV via USB. Right now I'm just hooking up a simple, small external drive, and it isn't the speediest. I'm going to try a faster drive to see if that makes a difference.

[erdem_ua]

We have some communication problems.

I did transcode one file to avi, and I did not have any sync issues with it. This was a file made up of a few h.264 pieces that was originally muxed into an mkv container; I transcoded it to xvid/ac3 in an avi container and had no sync issues. So that's another bit of info.

Do you transcode without re-encoding? When I say "transcode" I mean it's doesn't include any kind of re-encoding for audio and video. You needed to "copy streams" into AVI format instead of MKV container. You might use avidemux for it. Just use "copy" option for both audio and video codec part and use AVI for format section... If this transcoding solve the issue than we found the guilty one... This type of conversion is free from any kind encoding and it doesn't reduce your image quality and speedy... So it's acceptable work-around solution for the issue... Test it...

For consumer laws here (Turkey), you can even "return TV and have the price that you made" and also have other options like "free repair", "sale from TV price", and "change with another tv"...

[plasticassius]

Here is a related thought: Maybe it doesn't matter what type of container you "copy streams" to. If it's the copy process that fixes the container, possibly you could copy to an mp4 or mkv instead of an avi, and have it work.

[mxyzptlk]

Sorry I wasn't clear on the transcode/re-encode thing.

I actually re-encoded when I wanted to transcode. First I tried an application that describes itself as a transcoder, Transmageddon. However, the codecs changed, so I think it actually re-encoded the data streams instead of transcoding them into a different container.

I also attempted transcoding with avidemux, mencoder and ffmpeg, with no luck.

I tried to transcode with avidemux a few times; it either messed up the audio stream or left the audio stream out entirely. When I tried the one with the messed-up audio stream on the television, it wouldn't even rewind/fast-forward or skip. (For what it's worth, avidemux has some trouble with h.264 files and always spits out a big warning whenever you import one.)

Mencoder couldn't copy the audio stream -- had to do -oac pcm instead of -oac copy, so that wasn't a true transcode (uncompressed 16-bit PCM audio instead of AAC). Also tried forcing the audio copy with -fafmttag 0x706D, but again no audio on the television playback.

With ffmpeg, the file transcoded but still lost audio/video sync with rewind/fast-forward and pause.

So either I need to find a better way to effectively transcode, or we're back to the original question and the two-pass re-encode solution. As it stands:

• xvid video files in avi containers KEEP audio/video sync when rewinding/fast-forwarding, skipping ahead/back, or pausing;
• h.264 video files in mp4 and mkv containers LOSE audio/video sync when rw/ff, skipping ahead or back, or pausing;
• using ffmpeg to transcode h.264 files into avi containers also loses sync;
• re-encoding h.264 files with all the same specs as the original and two-passes KEEPS audio/video sync when rw/ff, skipping and pausing

(By the way, I just watched the freestyle/greco world wrestling championships from Turkey, and your user name popped up a lot -- Erdem was the name of a one or two wrestlers. Your country put on a fine event, but the Scottish announcer for the video stream couldn't get a single name right.)

[mxyzptlk]

Hey, I have my five posts now -- so I'll try posting the specs of one of the files that loses sync.

Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 2.30 GiB
Duration : 2h 13mn
Overall bit rate : 2 467 Kbps

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2h 13mn
Bit rate : 2 048 Kbps
Maximum bit rate : 5 865 Kbps
Width : 1 280 pixels
Height : 528 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.126
Stream size : 1.91 GiB (83%)
Writing library : x264 core 67 r1162M f7bfcfa
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=7 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=12 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=12 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=2048 / ratetol=1.0 / qcomp=0.50 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=24000 / vbv_bufsize=24000 / ip_ratio=1.10 / pb_ratio=1.10 / aq=1:1.00
Encoded date : UTC 2010-08-03 11:53:33
Tagged date : UTC 2010-08-03 11:56:07

Audio #1
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 2h 13mn
Bit rate mode : Variable
Bit rate : 125 Kbps
Maximum bit rate : 163 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 119 MiB (5%)
Encoded date : UTC 2010-08-03 11:55:12
Tagged date : UTC 2010-08-03 11:56:07

Audio #2
ID : 3
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 2h 13mn
Bit rate mode : Variable
Bit rate : 288 Kbps
Maximum bit rate : 373 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 276 MiB (12%)
Encoded date : UTC 2010-08-03 11:55:37
Tagged date : UTC 2010-08-03 11:56:07

[erdem_ua]

Do you try video as untouched (copy) and re-encode sound part with using CBR codecs? It might solve the issue too with much more speed!