Is there some reason you're reposting this here, and ignoring the comments you recieved in the original thread? The reason for posting the information here was that I though that it was pertinent to this group. As written in the original thread I found out that the problem was not with encoding, but rather with the decoding. I did not assume that both groups are read by the same people and decoding issues should be confined to the mencoder group.

With regards to the comments left in the original thread, I am not ignoring them. I am rather waiting to see if somebody can offer a fix, workaround or an alternative. If I understand the comments correctly, the consensus seems to be that the TS stream is regarded as faulty from an Mplayer/MEncoder perspective. That is too bad, but offers me no consolation as I do not get to decide what the local broadcaster chooses to send out. From my perspective, solely as a user, the input stream should be regarded as valid input, as it is what DVB-T STBs are provided with. Furthermore the TS stream is decoded correctly with other software such as VLC. My bad if you think I posted in the wrong group. All I'm hoping for is a workable solution for transcoding given TS streams to Xvid and/or x264. - Zed

On Thu, 2 Nov 2006 13:54:20 +0000 (UTC) Zed <zzuser@yahoo.com> wrote:

With regards to the comments left in the original thread, I am not ignoring them. I am rather waiting to see if somebody can offer a fix, workaround or an alternative. If I understand the comments correctly, the consensus seems to be that the TS stream is regarded as faulty from an Mplayer/MEncoder perspective.

My comment: "The aspect ratio is clearly wrong (5.11:1) but everything plays fine otherwise." Nothing about anything being faulty (except, perhaps your bugreport).

The problem is not the decoding, and certainly not the aspect change. You are quite right, my bad. I came to the wrong conclusion since the aspect ratio change was the only visible aspect of the original source material, even though the sample I cut out did not include this aspect ratio change.

First, it only happens with some vos, so this is a very good example why Again quite right. I have narrowed down the problem to a resolution change. The problem occurs when the resolution of the TS stream changed down from 720x576 to 704x576. Interestingly enough there is no problem going the other way.

you really should have included a full "mplayer -v" log, which is supposed to be the minimum requirement for every bug report. I, perhaps wrongly, assumed that this was redundant as the problems were not specific to a certain version and the source material exhibiting the issue was provided.

Second, the problem is not aspect change, but that the resolution of the video changes - so no wonder that you have no chance to encode it, you would at minimum have to insert a scale filter to keep the encoding size constant. Could you please elaborate on this suggestion? I have tried different -vf scale filters but with little use. I read the manual and I understood that the scale filters are applied postprocess and not preprocess. Don't I need to

However, I stand corrected and have uploaded the original material and a few new clips to demonstrate the issue to: ftp://upload.mplayerhq.hu/MPlayer/incoming/rezchange/ The following files are provided: ww.ts - the original material with a resolution change down (720->704) rezdown.ts - a new clip that demonstrates that the problem is replicable with other material rezup.ts - a new clip which shows that there is no problem the other way (704->720) aspect.ts - a new clip which contains an aspect ratio change from 4:3 to 16:9 In addition four txt files are provided and they contain the output of mplayer -v for each file in question. The aspect.ts has no playback problems, but I included it here due to the fact that I'm having a hard time maintaining the correct aspect ratio after the change. I've tried to scale the video and tried to apply the instructions in 13.10 Preserving aspect ratio (see below), but without result. I always end up with a 4:3 aspect ration for the whole file regardless of the change to 16:9. mencoder aspect.ts -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:trell:autoaspect -vf crop=714:548:0:14 -oac copy -o aspect.avi I uploaded the transcoded file (aspect.avi) and the mencoder output (mencoder_aspect.txt) and mplayer -v output (mplayer_aspect.txt) For some reason I am unable to upload to the rezchange directory and thus the aspect change files are in ftp://upload.mplayerhq.hu/MPlayer/incoming/aspect_change/ preprocess the input file in order to correct any resolution changes before handing over the file to mencoder in this proposed workaround? On that topic, any suggestions on such preprocess tools? Obviously I would prefer to use mencoder for the whole transcode process, if possible.

Problems at least partially fixed in SVN r20607. Thank you for the effort. I shall see if I can manage to get this new version compiled. Subversion or compilers are not my fortes as an end user.

- Zed P.S. Is it possible to autobreak over 80 character lines or at least highlight the offending lines when posting though the post form? 12345678901234567890123456789012345678901234567890123456789012345678901234567890

Hello, On Sun, Nov 05, 2006 at 11:29:43AM +0000, Zed wrote:

...

Problems at least partially fixed in SVN r20607. Thank you Reimar! Worked like a charm. Now if I could just get that auto aspect ratio detection to work ...

Remaining part to fix playback applied in SVN r20687. As said, for encoding the resolution change will break stuff, you have to make sure the encoder always gets the same resolution, e.g. via -vf scale=768:576 Best read the manpage part of -vf scale though, esp. for interlaced content you might want to take some additional parameters. Greetings, Reimar Döffinger