Am Samstag, 14. Januar 2006 21:37 schrieb Juergen Bausa: Hello, Jürgen. Thanks for your report.
> I cut out comercials from a movie recorded from dvb-s (german station 'das > vierte'). I think the audio chanel was mp2. Setting cutpoints went ok, but > after exporting the video in format 'dvd (dvbcut multiplexer)' and viewing > the resulting file in kaffeine (xine-based), audio was broken. There was > only some noise that sonded like the music of the movie at higher speed. > However, in kmplayer (using mplayer as the backend), sound was ok. Since I > was not sure, what my dvd player would do, I then used the option 'mpeg > program stream/libavformat'. The resulting video was ok in both kaffeine > and kmplayer. The resulting dvd also played well in my dvd-player. > > I think, there is something wrong in the dvbcut-multiplexer. If needed, I > could supply a part of the original ts-file for debugging. I have also observed this behaviour in xine some time ago. I tracked it down to a bug in the xine mpeg demuxer. I filed a bug report on sourceforge http://sourceforge.net/tracker/index.php?func=detail&aid=1379103&group_id=9655&atid=109655 but it seems that no-one of the xine developers noticed it. The point is, that dvbcut adds a few padding bytes in some places in order to "beautify" the output stream. To be precise, it prevents that the payload of a packet ends with a picture start code or audio sync word. If so, it introduces some padding bytes and moves the start code right to the beginning of the next packet. This is backed by 100% by the MPEG standard, as every pack header (which comes every 2048 bytes on a DVD) contains a field of 3 bits telling the number of padding bytes appended to the pack header. This way, one can add up to 7 padding bytes. (If one want to add more padding bytes, this value is set to 0 and a padding packet is added, but this has minimum size 6 bytes so you'll definitely need the packet header method for padding that amount to up to 5 bytes.) Unfortunately, the xine MPEG demuxer only takes 2 bits of that field in the pack header into account. Therefore, if there are 5 padding bytes in the pack header, xine accounts it as only 1 byte. Sorry, but this is plain wrong. I quoted the corresponding line of the source code in my bug report. There is no doubt that this field of the pack header consists of three bits. It is explicitly described in the MPEG ISO standard, and you will also find it here for example: http://dvd.sourceforge.net/dvdinfo/packhdr.html The result is, that you will notice a flicker of the video every once in a while (not that often, though). In certain audio configurations (I think it was 192kb/s stereo MP2), xine will discard every other audio packet because it has 5 padding bytes which xine interprets as 1 padding byte and therefore the last four padding bytes are considered audio data, which turns out to be invalid. That means... the problem is not in DVBCUT, it is in xine. MPlayer, and all players that are not xine-based and do not use the xine MPEG demuxer, play fine. If you produce a DVD from it, any DVD player should play fine (at least concerning this issue). So the only thing you cannot do with that DVD, is play it in xine. I hope that the xine people will pay attention to my bug report some day... Bye, Sven. -- Sven Over Stephanienstr. 9 76133 Karlsruhe Telefon: 0721-9204199 http://www.svenover.de/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ DVBCUT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dvbcut-user
