Encoding from preview & AAC ER parametric ERRORS!


Getting this to work is very difficult in any Vidcoder version I have used. Encoding a short 15 second shortclip(size makes no difference!) using either mp4 or mkv as a container just keeps reloading the video like a loopback issue with Media player Classic loading at the end of the second time. Can't get it to work at all! Is it a bug?

Below is part of log which deletes itself after "exiting early" has been deleted and loads up again for the 2nd time again(and in log again when clip is generated) after 1st preview has finished. No encoding of clip is ever done!

1st time
[19:17:08] sync: first pts is 4665
[19:17:25] sync: reached pts 1352261, exiting early

2nd time
[19:18:34] aac-decoder done: 0 frames, 0 decoder errors, 0 drops
[19:18:34] mux: track 0, 359 frames, 829020 bytes, 441.70 kbps, fifo 512
[19:18:34] mux: track 1, 704 frames, 181929 bytes, 96.93 kbps, fifo 1024
[19:18:34] libhb: work result = 0

Finished preview clip generation. Size: 999 KB

After creating a mp4 in an mkv container I noticed Media Info tool reading the pass thru aac audio which now won't play, as ER parametric after encoding! I checked it again in Yamb which also shows it as the same. My video was okay, but the audio integration very messed up. I had to use mkv extract, but it would not extract the aac due to this error. The pass thru audio was damaged, so I had to extract the video only and remux the original audio back from another folder.
The passthru is great with mp3, but is very hit and miss with aac I find, is that the issue or is it just the final muxing process?

Both issues were not reflected in the log files as the processes finished!!!

file attachments

Closed Aug 23, 2013 at 2:56 AM by RandomEngy
Fixed in 1.5.5 Beta


RandomEngy wrote Aug 12, 2013 at 6:51 PM

The way AAC is passed through is the responsibility of the HandBrake library, not VidCoder. Please check whether the same thing is working or broken in the official HandBrake client.

Datauser wrote Aug 13, 2013 at 3:28 PM

Will do. I repeated procedure last night with Vidcoder getting same end result. Here's the log for now.

Datauser wrote Aug 13, 2013 at 4:00 PM

Installed Handbrake. Regarding issue of encoding a clip. If I'm not mistaken, you cannot encode a clip in handbrake using preview, unless I'm not seeing this option? Therefore the issue is solely Videcoder's as it has this option. I'm now going to encode in handbrake using aac passthru to check the issue I reported to you. Report tomorrow.

RandomEngy wrote Aug 13, 2013 at 4:02 PM

You can just specify a small time range in the middle of the video in HandBrake and that will be equivalent. Though I thought it also had the ability to encode a preview clip.

Datauser wrote Aug 13, 2013 at 4:57 PM

Like I said unless I'm not seeing this option, because I'm missing it from my lack of GUI familiarity doing a clip from its preview is definetly not there, so bug must be Vidcoder's.

Datauser wrote Aug 13, 2013 at 5:00 PM

For future reference I must try auto pass thru too with aac to see if that replicates the bug I saw.

RandomEngy wrote Aug 13, 2013 at 5:27 PM

There is a preview clip functionality in HandBrake. Click in the "Preview" button, then press "Play". And please note that some problems with encoding happen only when you select a small time range out of the title. I'm calling HandBrake functionality to pick this time range and they don't always do the job correctly.

Datauser wrote Aug 13, 2013 at 8:44 PM

I did a quick 1 pass encoding mkv container with Handbrake and the issue is a Vidcoder one using aac pass thru rather than Handbrake.

The encoding came out perfect with no frozen video due to muxing or damaged audio. To check all extracted using mkv extractor from the container and remuxed okay using toolnix unlike the Vidcoder encoder one. I coincided this encoding on another laptop using 1pass and aac pass thru gave the same error result as my previous aac pass thru log which was 2 pass and I attached before.
New Log below showing handbrake success.

RandomEngy wrote Aug 14, 2013 at 6:32 AM

VidCoder is reporting failed because it saw this error message during the encode:

Invalid byte for codeset in input, discard byte.

HandBrake also had this error message happen during the encode but it reported success. Was the resulting file from each of VidCoder/Handbrake good or bad?

Datauser wrote Aug 14, 2013 at 10:53 AM

Yes, I noticed that too! Vidcoder unsuccessful because of bad byte, Handbrake proved successful. Resulting file from Handbrake played fine and using mkv toolnix extracted to individual components fine as a check and remuxed back together.
Vidcoder wouldn't extract the audio because it was changed or damaged in some way(only video extracted & srt) and in its full encoded form was not recognised by any media player software or hardware.

Datauser wrote Aug 14, 2013 at 10:56 AM

I'm using portable version of Vidcoder by the way!

RandomEngy wrote Aug 14, 2013 at 2:39 PM

Was the 1-pass encode from VidCoder also unplayable? If so I don't see anything else different in the logs; sending a sample video to encode and your exported preset would be helpful.

Datauser wrote Aug 14, 2013 at 8:42 PM

1 pass failed too with Vidcoder. Everything was on default, anyway I'm going to try it out with auto pass thru now 1st and 2 pass using same source. I think the problem is the aac passthru which messes things up(or Vidcoder portable??? as they are known to behave differently to their parent time to time!!!) rather than 1 or 2 pass. Profile exported!

Datauser wrote Aug 14, 2013 at 8:52 PM

For some reason the exported profile is showing incorrect target size of 448mb instead of 398mb for bitrate 340 which is set in options. Ignore that. I reverted settings back to correct exported profile I used: attached now

Datauser wrote Aug 15, 2013 at 9:58 AM

Encoding using auto passthru 2 pass which I did last night on the same source reflects the same errors as the earlier aac pass thru but surprisingly the file and audio plays okay, nothing effected! Log attached. So it looks like something in the aac pass thru option after all which is the problem, but you can decipher the log better than I as the log states below aac passthr was used in the end in anycase after it switched from auto passthru.

[03:26:03] Auto Passthru: no valid fallback specified
[03:26:03] Auto Passthru: using AAC Passthru for track 0

RandomEngy wrote Aug 16, 2013 at 8:17 PM

I tested some today and I was able to reproduce the problem. AAC passthrough does seem to be broken. The root of the issue is that I needed to set the sample rate and I wasn't doing that. This fix will be in the next beta. For now just use Auto Passthrough.

Datauser wrote Aug 17, 2013 at 11:21 AM

Great news you pinned it down. Just goes to show why logs and user feedback are vital to isolate a bug. Never understood why some people moan about this and that problem, but never submit their log. Thankyou for your valid work.