1

Closed

Re-Remuxing Due to audio error

description

I am feeding mpeg2 .wtv files in to the following profile:
[TS Unprocessed]
Description=Use this to copy the H.264 WTV/DVRMS files to TS format and to remove commercials from your TS videos. It does not remove black bars, resize the video, deinterlace or select audio language. Use this if you have HD recordings which don't need processing.
order=copy,ffmpeg
copy-ext=.ts
copy-audiodelay=skip
ffmpeg-general=-threads 0
ffmpeg-video=-vcodec copy -f mpegts -map 0:a -map 0:v
ffmpeg-audio=-acodec copy
ffmpeg-audioac3=-acodec copy
ffmpeg-ext=.ts
ffmpeg-audiodelay=skip
FixedResolution=true
SkipCropping=true
AllowH264CopyRemuxing=true
With the following config file:
[FFMpegBackupRemux]
CopyRemux0=-i <source> -vcodec copy -acodec copy -map 0:a -map 0:v -f mpegts
SlowRemux0=-i <source> -vcodec libx264 -b 7000k -flags +ildct+ilme -x264opts interlaced=true:me=hex:trellis=2:subq=8:partitions=all:8x8dct=1:ref=8:rc-lookahead=50:keyint=25:min-keyint=20:bframes=3:weightb=1:level=4.1:b-pyramid=normal:direct=auto:mixed-refs=1:deblock=-1,-1:no-fast-pskip=1:no-dct-decimate=1:b-adapt=2:threads=auto -map 0:a -map 0:v -acodec copy
SlowRemux1=-i <source> -vcodec libx264 -b 7000k -flags +ildct+ilme -x264opts interlaced=true:me=hex:trellis=2:subq=8:partitions=all:8x8dct=1:ref=8:rc-lookahead=50:keyint=25:min-keyint=20:bframes=3:weightb=1:level=4.1:b-pyramid=normal:direct=auto:mixed-refs=1:deblock=-1,-1:no-fast-pskip=1:no-dct-decimate=1:b-adapt=2:threads=auto -map 0:a -map 0:v -acodec ac3 -ab 384k
Most of my files fast remux fine, as I believe they should, even when fed a h264 profile.

Some however take a long time to complete, first they slow remx due to audio error, then they re-remux again due to audio error.

In the log, i see repeated lines about not being able to find the codec, or something similar. Maybe another ffmpeg problem?

file attachments

Closed Apr 13, 2013 at 9:08 PM by rboy1
ffmpeg issue

comments

rboy1 wrote Feb 28, 2013 at 7:54 PM

This is a bug, I'll fix in the next release.

The remuxing due to 0 channel audio is due to an issue with the recording that the hearing imparied track has no audio / data, for some reason ffmpeg still copies the track which breaks the encoders down the line.
I' had put a fix to remux ignoring the 0 channel audio track, but it looks like there's a bug in the code and it isn't remuxing the "correct" track.

rboy1 wrote Feb 28, 2013 at 8:04 PM

Can upload a sample video (100MB size) I can test.

Dodgexander wrote Feb 28, 2013 at 8:30 PM

Is this the same issue as another I am having?

I have been tuning the default comskip.ini file contained in the MCEBuddy program folder.

When I change padding=0 too padding=6 and feed the file into MCEBuddy, the result is a file with only the hearing impaired soundtrack.

When I go back to padding=0 it copies the normal soundtrack.

See test5.wtv-Default-2013-02-28T19-54-29.0206879+00-00.log

rboy1 wrote Feb 28, 2013 at 8:44 PM

FYI - what you're trying to do will not work here. the mpeg2video is copyremuxed and then your profile also just copies it over again. So there is no recoding to H264.

You've got a conundrum here, while trying to save a remux, your setup cannot process mpeg2video (since it was customized to work with H264 remuxing).

There's an advanced way to handle this using another encoder like handbrake to handle the mpeg2video to H264 video conversion.
Add the line
ffmpeg-unsupported=mpeg2video+wtv
This will make ffmpeg encoder skip the mpeg2video
change the order line
order=ffmpeg,handbrake
so when ffmpeg skips, it will fallback to handbrake

and add these lines:
handbrake-general=--decomb --loose-anamorphic --verbose=2 -T -f mp4 -4
handbrake-video=--start-at duration:3 -e x264 -b 1800 -x me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=8:rc_lookahead=50:keyint=25:keyint_min=20:bframes=1:weight_b:level_idc=41:b_pyramid=normal:direct_pred=auto:mixed_refs:deblock=-1,-1:nofast_pskip:nodct_decimate:b_adapt=0:threads=auto
handbrake-audio=-E faac -6 auto -R auto -B 160 -D 0
handbrake-audioac3=-E faac -6 auto -R auto -B 256 -D 0
handbrake-ext=.mp4
handbrake-audiodelay=skip

Dodgexander wrote Feb 28, 2013 at 8:53 PM

These are mpeg2 .wtv files though, not h264 ones.

How come it works with all the other files fine? Its just when i change comskip that there is a problem.

rboy1 wrote Feb 28, 2013 at 9:09 PM

No this is a different issue, AViDemux is not taking all the audio tracks during the merging after commercial removal.

can you upload the original video for this log file to test and see what's going on.

Dodgexander wrote Feb 28, 2013 at 9:20 PM

This is mpeg2.wtv >>> mpeg2.ts conversion. No h264.

rboy1 wrote Feb 28, 2013 at 9:42 PM

because I suspect when you changed the comskip settings, comskip did not produce any segment of video to cut, if there is no cutting this issue won't come up and it works fine.

anyways I've fixed it in the next build.

There is a simple work around for it, you can select the language in the conversion settings, that way it will pre filter the audio track before the cutting and this problem won't arise.

Dodgexander wrote Feb 28, 2013 at 10:08 PM

Thanks, but the language selection doesn't make a difference, presumably because the hearing impaired track is also english.

The only setting I changed in comskip was the padding, which is just a delay to when to cut the comercial. The delay itself works, but the audio track is always the mono hearing impaired track.

I'm uploading a sample and log as we speak anyway, so you should be able to check it out.

rboy1 wrote Mar 2, 2013 at 9:59 PM

Fixed

** Closed by rboy1 28/02/2013 18:12

Dodgexander wrote Mar 2, 2013 at 10:01 PM

The new version has fixed, some, but not all my fails. A considerable amount still re-remux due to audio errors, then slow remux. As before.

I am uploading the following files to the server for you to have a look:

mpeg2slowremux.wtv
mpeg2slowremuxB.wtv

Thanks :)

Dodgexander wrote Mar 2, 2013 at 10:01 PM

Fails= Files* sorry

rboy1 wrote Mar 2, 2013 at 11:21 PM

That's because that files had 0 channel audio tracks after remuxing so they need to be re-remuxed to fix it.

WARNING> 2013-03-02T21:39:15 MCEBuddy.AppWrapper.FFmpegMediaInfo --> 0 channel audio track reported

In future, check for this in the log file before posting, I have explined it earlier also. this is not a bug but a design feature to ensure properly audio.

Dodgexander wrote Mar 2, 2013 at 11:36 PM

Interestingly it seems to be intermittent, if I feed the same file several times, sometimes it finds an audio error and re-remuxes and sometimes it fast remuxes fine. Odd.

Dodgexander wrote Mar 2, 2013 at 11:37 PM

Spoke too soon, it fast remuxes, then re-remuxes, then slow remuxes.

Dodgexander wrote Mar 2, 2013 at 11:44 PM

Why does it have 0 audio tracks? The original files play back fine with audio.

Dodgexander wrote Mar 2, 2013 at 11:47 PM

Here is a screenshot of one of the files being played back: http://aluminas.net/v?ID=3fdda7

Is it something to do with the fact the hearing impaired track is a higher bitrate than the normal?

Dodgexander wrote Mar 3, 2013 at 12:49 PM

You might also want to see ffmpeg ticket 566 , 948, 2159.

Im no expert but, I have a good guess it is re-remuxing the audio is this:

A- ffmpeg always uses the highest bitrate audio track first (this is hearing impaired)
B- during commercials at the start of a recording the hearing impaired track has no audio. This results in ffmpeg producing error:
"cannot find codec parameters" or "channel = 0 contains zero channel audio.

This also explains why this error message appears on channel E4 in the UK compared to other recordings I have for Channel 5 or 5 star. E4's hearing impaired soundtrack is a higher bitrate than its normal one, compared to the other channels, which work fine.

Dodgexander wrote Mar 4, 2013 at 10:58 AM

Okay, it doesn't happen with all E4 recordings, just some. I still think it is a bug though.

rboy1 wrote Mar 13, 2013 at 11:09 PM

invalid

** Closed by rboy1 10/03/2013 08:49

Dodgexander wrote Mar 13, 2013 at 11:10 PM

Ramit, I am sorry to re-open, but this still hasn't be resolved. A lot of files still Re-Remux due to audio errors.

Dodgexander wrote Mar 15, 2013 at 1:36 AM

Please see additional files I added to my folder on server. test0.log and test0.wtv. This file goes to audo re-remux about 3 times, takes roughly 4 hours to complete.

rboy1 wrote Mar 15, 2013 at 4:01 PM

That's because there is a 0 channel audio track in the file after remuxing.

WARNING> 2013-03-14T16:07:26 MCEBuddy.RemuxMediaCenter.RemuxMCERecording --> Found 0 channel audio track in remuxed file


I'm sorry but there's nothing I can do about it because it's an ffmpeg issue, can I can't update ffmpeg until the dev's fix the WTV mjpeg ticket I've opened which has caused wtv remuxing to fail.

Dodgexander wrote Mar 15, 2013 at 9:29 PM

Thanks Ramit, I see your case on ffmpeg, they aren't being too helpful, unfortunately.