Hi!

After authoring a DVD with VOB streams exported from KDEnlive, I have a problem with the resulting DVD on my standalone set top box DVD player - it isn't able to seek in the stream, when trying to jump to a position it starts playing the chapter from the beginning.

On the web I've found information that this might be because of lack of video sequence headers at beginning of GOPs in the stream.

Does KDEnlive with its default DVD format settings generate those headers? What argument to kdenlive_renderer decides that? Maybe the export template doesn't specify the needed option?

Does anybody know an Open Source dump utility for VOBs?

One which would dump the information about the VOB video stream's GOP structure, tell me whether video sequence headers are present etc.

I want to compare the VOBs exported from KDEnlive with known good VOBs from commercial DVDs.

I've found a tool that can be used do analyze VOB files - http://dvbsnoop.sourceforge.net/.

I've compared a VOB file fomr commercial DVD with VOB files from KDEnlive and they exhibit this thing that commercial DVD's dont have:

------------------------------------------------------------
SECT-Packet: 00000267   PID: (Unkown PID), Length: 17 (0x0011)
from file: ../../Pawlik_2007-05-03_Nagusek/output/2007-05-03_Nagusek.vob
------------------------------------------------------------
  0000:  3c 70 0e 3c 0c 5f fe d8  e1 6f aa 30 38 40 7a ba     0010:  c4                                                 .

Guess table from table id...
DSM-CC-decoding....
Table_ID: 60 (0x3c)  [= DSM-CC - Download Data Messages (DDB)]
Section_syntax_indicator: 0 (0x00)
private_indicator: 1 (0x01)
reserved_1: 3 (0x03)
dsmcc_section_length: 14 (0x000e)
table_id_extension: 15372 (0x3c0c)
reserved_3: 1 (0x01)
Version_number: 15 (0x0f)
Current_next_indicator: 1 (0x01)  [= valid now]
Section_number: 254 (0xfe)
Last_section_number: 216 (0xd8)
DSM-CC Message Header:
    protocolDiscriminator: 225 (0xe1)
     ==> wrong protocol discriminator (should be 0x11)
    Message header bytes: 
          0000:  6f aa 30 38                                        o.08
    moduleId: 16506 (0x407a)
    moduleVersion: 186 (0xba)
    reserved: 196 (0xc4)
    blockNumber: 55296 (0xd800)
    Block Data: 
    Checksum: 1081785028 (0x407abac4)
    ==========================================================

Anybody knows what this wrong protocol discrimintor is about?

Could it be caused by KDEnlive supplying wrong options to MLT, or MLT wrong arguments to FFMPEG functions, or a bug in FFMPEG itself?

Or maybe this isn't harmful? But why commercial VOBs don't exhibit this?

I've been trying to create a DVD with kdenlive and faced similar issues.

It seems that the 'vob' file created by kdenlive_renderer does not contain the required 'NAV' packets.

This is strange because it uses the 'format=dvd', and in ffmpeg/libavformat/mpegenc.c where the 'dvd'

format is defined, it says:

/* Same as mpeg2vob_mux except the 'is_dvd' flag is set to produce NAV pkts */

so you would think the NAV packets would be there... but they aren't.

I managed to make progress by using

ffmpeg -i movie.vob -f mpeg2video -vcodec copy movie.mpeg

to extract the video part,

ffmpeg -i movie.vob -f ac3 -acodec copy movie.ac3

to extract the audio part, then

mplex -f 8 movie.ac3 movie.mpeg -o movie2.vob

to create a vob with the right NAV packets.

dvdauthor is much happier with this new vob, and creates

a dvd that I can navigate much better (I hesitate to say 'perfectly'

as I haven't tried everything yet).

Now to figure out why libavformat gets it wrong... I tried

ffmpeg -i movie.vob -f dvd -vcodec copy -acodec copy newmovie.vob

to see if that would get it right, but it hangs after a while...

Use Avidemux 2. Nice user-friendly GUI for ffmpeg. It can fix various issues with both importing and exported video from Kdenlive without need of reencoding. Use copy/copy/MPEG2 PS method.

Thanks for the pointer to avidemux. I'll have a play with it and add it to my tool box.

However I really rather that it worked with as little fiddling as possible, so I dived into

the code and eventually managed to find something.

mpegenc tries to put in the NAV packets, but fails. I've manage to get it to succeed.

I'm not sure of all the implications of the change I have made, but it seems to make

sense and definitely improves the results that I am getting.

In ffmpeg/libavformat/mpegenc.c, in the function mpeg_mux_write_packet, towards the end, around line

1170, there is a section

    if (s->is_dvd){
        if (is_iframe && (s->packet_number == 0 || (pts - stream->vobu_start_pts >= 36000))) { // min VOBU length 0.4 seconds (mpucoder)
            stream->bytes_to_iframe = av_fifo_size(&stream->fifo);
            stream->align_iframe = 1;
            stream->vobu_start_pts = pts;
        } else {
//            stream->align_iframe = 0;
        }
    }

The original doesn't have the "stream->align_iframe = 0;" commented out. Commenting this line

fixes the creation of DVD VOBs for me.

The patch suggested by Neil Brown has just been committed to FFMPEG svn, so the issue should be fixed now, great.

Thanks Neil for investigating this issue.

Regards