Freebox recordings: Sound out of sync in Avidemux

Started by aviphil87, August 02, 2015, 03:05:05 PM

Previous topic - Next topic

aviphil87

Dear all,

I record HD TV on a Freebox HD. Video codec is H264, audio codec AACn, filetype .ts. These files are not just exactly HD, because the image size is 1440x1080.

When I play these files directly from the Freebox, they play end-to-end, and sound remains lip sync all the way.

After I transfer these files on a PC using Filezilla, when I play these files with Avidemux 2.6.9 (2.6.10.150607 idem), with OpenGl support disabled:
   - those recorded from FR3, sometimes they play fine end-to-end, sometimes the sound gets more and more late behind the image,
   - those recorded from other channels, i.e. Arte, always the sound is sync at the beginning, and gets late and late as the video plays (about over a second late every hour).

Now, I take a FR3 file that plays fine and stays in sync. I input it in 2.6.9 to convert it to, say, .mp4 with image size 1280x720 to take much less space. After a variable processing time (from one second to twenty minutes or more) I get a crash with message "The video has been saved but seems to be incomplete".

Obviously there are corruptions in the Freebox file. Somehow the Freebox firmware knows how to overcome the corruptions. Avidemux apparently does not. Should I check and fix the file before opening it in 2.6.9 (tried 2.6.10 behaves same), and how?

Any idea perhaps?

Thank you,

Jan Gruuthuse

Hard to tell. (Freebox Hd = tv via (x)DSL telephone line, broadband internet?
Are you editing the video before transcoding? Like cutting away commercial breaks?
Or are you having audio stream changes: like drop of AC3 5.1 when switching from movie to commercial break?
Normally when a original video stream plays correctly with VLC, there should be not a big issue with it.
Avidemux should not be used to play video, it is not one of its strong points.
You could overdo the transcoding, requiring to much processor calculation to restore picture/audio.
Or there could be an issue while
- receiving the stream (small packet drops, ...)
- recording the stream on the box: media used to record to slow, viewing other channel while recording, ...

Try re-muxing stream to mkv before transcoding with avidemux with mkvtoolnix this could solve small issues with the stream integrity.

What is the used Hardware and its Operating System.
Are you just resizing video or are you using other optimalisation to reduce the file size.
Can you save the used settings and attach that saved file to your posting?
Load the video, make your settings and save these:
Avidemux: Menu: File: Tinypy Project: Save As Project. You should have a file now with the .py extension.

Other user(s) may have other ideas / proposals
If you can pinpoint the issue, make a 1 minute recording. Transcode that that recording and upload both to an internet service like dropbox. Free access without login to download.

Plenty of guessing: as I'm not familiar with (x)DSL TV or the used Freebox HD
PS: Filezilla file transfer, you are using LAN cable and not wifi?

mean


aviphil87

Jan, sorry for delay answering, in respect to the time you took answering me. But I got such wow results from converting into .mkv, that I wanted to take time for enough tests to make sure.

Short answer: MKVToolNix 8.2.0, bingo!

Some more detail:
   - any .ts file recorded from a DSL box and crashing Avidemux with a "File too short" message, once converted into .mkv, no more crash,
   - any such .ts file that did not crash showed image and audio going gradually out of sync. Once converted into .mkv, image and audio stay lip-sync,
   - even very badly recoded .ts file, with plenty of pixels and mosaics, converting them into .mkv does not fix pixels (how could they) but, for any purpose it may serve, stay lip-sync.

Hope this helps, thank you very much again for your time, cheers,

Jan Gruuthuse

Thanks for your report. It would still be helpful if you could post a small original sample of this problematic recording.  1 minute or so in duration.  So developers could look at that problem. Perhaps there could be a possible solution in Avidemux?