dvd/vob "decoder" part 1: the system itself
Hello; Included are the files, and patches needed for the dvd decoder. I threw away my original system on trying to insert packets into the main stream (as the "attachment/data" type stream). The reason for that is that the dvd data stream, that contains commands for the client can change/insert packets "in the past". Example; a user seeks back. The DVD ifo system will insert packets containing "change the subtitle color" so it works ok for the displayed cell/chapter. LibAV doesn't expect new packets inserted "backwards" in the stream, and the buffer system gets all messed up because packet sizes are off. Changing to a new system means my "hack" on decoding the packet header isn't needed any more, and except for stream flagging the mpegps demuxer should be unchanged. My attachment decoder is not needed anymore (for those who looked at it, only dvd_protocol.c/h are still needed). The new system uses a callback, that the user registers. This is, after much experimenting, the best way I could come up with. The callback though is registered per protocol, and thus changes are needed in "gasp" URLContext. Reason for keeping it per context? Well, a user can be reading from several dvd devices at the same time if he/she uses the avlibs. Or some end devices (like the ps3) send several request to open a file at the same time. If one callback is registered for the whole library, this messes up the system. Whats send in the callback? Basically AVDVDParseContext packets. They contain a type (the enum effdvd_Type ) that tells the end-user app what should be done, and a pts timestamp in dvd time (90000/tick). The packets should be handled at that time. There are some packets which are obvious (like: new subtitle palette) and some that are not. The most important one is effdvd_Reset_IFO. effdvd_Reset_IFO asks the end-user app: clear your streams, flag all streams you are using as invalid (more later on that), and be prepared to re-init all your codec decoders. Why does one need to do that? Because a vob file 1 might contain audio data in ac3 with 2 channels, while a vob 2 might have it in 6 channels. Or the resolution of the video stream might change (from dvd pal to dvd ntsc widescreen for example). First; DVD's may contain up to 64 streams. One of the patches changes the MAX_STREAMS constant to match that. Second; Stream re-init. I implemented this by adding a flag to AVStream (at the end, discard_flags). Set this to one in end-user app, and this will tell the demuxer that this stream has been discarded by user (user closed all codecs, etc). It works by telling the demuxer that once it dedects a certain packet type, and normally does a av_new_stream; don't re-add the stream to the end of the new list (pushing more and more streams on the list). Example; suppose the discard_flag is set to 1 for the video stream (and we only have one). When a new packet is received by the demuxer, its loop will not find a valid video stream anymore. It thus will create a new one, but will fill the slot for the "old" video stream with the new video stream. Don't know if this text makes sense, bit a quick look at the code should be helpful. Why not do this in the protocol reader? Basically 1) because the protocol doesn't and shouldn't know about the streams and 2) because the end-user needs to close and free his/her decoders. Once that's done, the demuxer doesn't even know. Next; chapter seeking. I added a new flag for that: #define AVSEEK_FLAG_DIRECT 8 ///< seek directly, skipping any stamps and translation #define AVSEEK_FLAG_CHAPTER 16 ///< seek to chapter, if supported Using that will basically use av_seek_frame() to override a search like it does for AVSEEK_FLAG_BYTE. The arguments timestamp will thus position chapters, instead of timestamps. Summary; whats the total change; 1) The whole setup adds a protocol handler called ffdvd. User inits his open file with av_open_input_file ("dvdread:e:/") or av_open_input_file("dvdread:/cdrom1/") 2) User registers a callback by using url_fset_protocol_callback(), a new function in avio.c. I tried to make it generic. 3) User polls streams as before for audio/video 4) User can get callback events from the protocol, with timestamps. 5) Events get examined for the timestamps on the protocol packet, and handled upon. 6) When needed, these events are executed, and for some functions a notify is send back (example, when user selects a button dvd_protocol_select_button() is called). 7) That's it. How well does this all work? I build a example app separate from ffmpeg, on which rather big changes are going to be needed. Note that these changes have almost nothing to do with the dvd protocol handler. They are mostly implementing the "we should look at this/this is wrong/etc" comments (example; discarding new streams). I have ffplay ok, but will need to work with someone on ffmpeg. Source is. Offcourse available. I am attaching the main files here, and the most important patches. Since I am not sure on how the continue on this, please tell me how this needs to be handled (ege do patches first, what order,. Etc. ) If the system is accepted, at least one patch needs a major version bump. I should probably split up some patches too. Note 2; I need to talk to the people for libdvdread, since I fixed a few problems in their code (and added one function to read attributes that its not available now dvdnav_get_video_attributes()). To have this working, we would offcourse also need to depend on libdvdread (if the user enabled it by ./configure, changes for makesfiles and that needed). Note 3: we will probably need some commandline extensions to specify seeking to a chapter, etc. for ffmpeg I have worked on and of on this for the better part of 2 months figuring out the best and least intrusive way. If this all gets rejected, I am fine with that. If it doesn't, also. Just let me know. Erik
Replying to myself also; I sent everything as one big bunch of files and changes (and that's even with the end-user app changes). If anyone looks at this, the changes probably need to be discussed patch per patch. I am open to any input (or feedback) on this. Erik
Hi, i hope you are still around and havnt given up yet on this ... On Sun, Jul 12, 2009 at 02:00:33AM +0200, Erik Van Grunderbeeck wrote:
Hello;
Included are the files, and patches needed for the dvd decoder.
I threw away my original system on trying to insert packets into the main stream (as the "attachment/data" type stream). The reason for that is that the dvd data stream, that contains commands for the client can change/insert packets "in the past". Example; a user seeks back. The DVD ifo system will insert packets containing "change the subtitle color" so it works ok for the displayed cell/chapter. LibAV doesn't expect new packets inserted "backwards" in the stream, and the buffer system gets all messed up because packet sizes are off.
please elaborate on what the problem with this is. It should have worked from how i understand it, at least if all packets have correct timestamps
Changing to a new system means my "hack" on decoding the packet header isn't needed any more, and except for stream flagging the mpegps demuxer should be unchanged. My attachment decoder is not needed anymore (for those who looked at it, only dvd_protocol.c/h are still needed).
The new system uses a callback, that the user registers. This is, after much experimenting, the best way I could come up with. The callback though is registered per protocol, and thus changes are needed in "gasp" URLContext. Reason for keeping it per context? Well, a user can be reading from several dvd devices at the same time if he/she uses the avlibs. Or some end devices (like the ps3) send several request to open a file at the same time. If one callback is registered for the whole library, this messes up the system.
Whats send in the callback? Basically AVDVDParseContext packets. They contain a type (the enum effdvd_Type ) that tells the end-user app what should be done, and a pts timestamp in dvd time (90000/tick). The packets should be handled at that time.
There are some packets which are obvious (like: new subtitle palette) and some that are not. The most important one is effdvd_Reset_IFO.
effdvd_Reset_IFO asks the end-user app: clear your streams, flag all streams you are using as invalid (more later on that), and be prepared to re-init all your codec decoders.
Why does one need to do that? Because a vob file 1 might contain audio data in ac3 with 2 channels, while a vob 2 might have it in 6 channels. Or the resolution of the video stream might change (from dvd pal to dvd ntsc widescreen for example).
First; DVD's may contain up to 64 streams. One of the patches changes the MAX_STREAMS constant to match that.
Second; Stream re-init. I implemented this by adding a flag to AVStream (at the end, discard_flags). Set this to one in end-user app, and this will tell the demuxer that this stream has been discarded by user (user closed all codecs, etc).
It works by telling the demuxer that once it dedects a certain packet type, and normally does a av_new_stream; don't re-add the stream to the end of the new list (pushing more and more streams on the list). Example; suppose the discard_flag is set to 1 for the video stream (and we only have one). When a new packet is received by the demuxer, its loop will not find a valid video stream anymore. It thus will create a new one, but will fill the slot for the "old" video stream with the new video stream. Don't know if this text makes sense, bit a quick look at the code should be helpful.
Why not do this in the protocol reader? Basically 1) because the protocol doesn't and shouldn't know about the streams and 2) because the end-user needs to close and free his/her decoders. Once that's done, the demuxer doesn't even know.
Next; chapter seeking. I added a new flag for that:
#define AVSEEK_FLAG_DIRECT 8 ///< seek directly, skipping any stamps and translation #define AVSEEK_FLAG_CHAPTER 16 ///< seek to chapter, if supported
Using that will basically use av_seek_frame() to override a search like it does for AVSEEK_FLAG_BYTE. The arguments timestamp will thus position chapters, instead of timestamps.
Summary; whats the total change;
1) The whole setup adds a protocol handler called ffdvd. User inits his open file with av_open_input_file ("dvdread:e:/") or av_open_input_file("dvdread:/cdrom1/") 2) User registers a callback by using url_fset_protocol_callback(), a new function in avio.c. I tried to make it generic. 3) User polls streams as before for audio/video 4) User can get callback events from the protocol, with timestamps. 5) Events get examined for the timestamps on the protocol packet, and handled upon. 6) When needed, these events are executed, and for some functions a notify is send back (example, when user selects a button dvd_protocol_select_button() is called). 7) That's it.
How well does this all work? I build a example app separate from ffmpeg, on which rather big changes are going to be needed. Note that these changes have almost nothing to do with the dvd protocol handler. They are mostly implementing the "we should look at this/this is wrong/etc" comments (example; discarding new streams). I have ffplay ok, but will need to work with someone on ffmpeg. Source is. Offcourse available.
I am attaching the main files here, and the most important patches. Since I am not sure on how the continue on this, please tell me how this needs to be handled (ege do patches first, what order,. Etc. ) If the system is accepted, at least one patch needs a major version bump. I should probably split up some patches too.
Note 2; I need to talk to the people for libdvdread, since I fixed a few problems in their code (and added one function to read attributes that its not available now dvdnav_get_video_attributes()). To have this working, we would offcourse also need to depend on libdvdread (if the user enabled it by ./configure, changes for makesfiles and that needed).
Note 3: we will probably need some commandline extensions to specify seeking to a chapter, etc. for ffmpeg
I have worked on and of on this for the better part of 2 months figuring out the best and least intrusive way. If this all gets rejected, I am fine with that. If it doesn't, also. Just let me know.
I definitly want this in ffmpeg, so no reject nitpick: we use spaces not tabs also try tools/patcheck these of course are not truly important and it would probably be unwise to spend much time on cleaning this up for some parts of the code Some comments 1. First the av_seek_direct() code looks good, if you could send this as a seperate patch (also please name it av_seek_protocol() and AVSEEK_FLAG_PROTOCOL) i suspcct we should be able to commit this quickly 2. AVSEEK_FLAG_CHAPTER should be ok as well if you could send this as a seperate patch. But note the parametr should be an absolute chapter number not a relative to current position or you will have to deal with packet fifos between demux and decode causing a delay and +-1 errors close to chapter transitions 3. iam against stream reusal, stream numbers must be unique, we cant just by seeking around have chapter 5 use stream 1 as video and when we seek back video is stream 0 with audio stream 1. (this can happen if streams are marked "discard" and reused. 4. about the callback, i think this will need to be changed somewhat as is i see 2 issues A. thread sync B. every application would need a buffer to make sure the data from the callback is delayed and processed at the correct time (that is the time matchng what went through demux & decode with all its fifos) I thus think some way to pull data out like av_read_frame() seems a bit easier to handle. 5. If we had a data stream instead of a callback, stream copy to arbitrary containers might work somewhat. With a callback all callback provided information would be lost, i dont know if this would lead to any problem or not with actual DVDs being stream copied to mkv/nut/avi whatever more comments below [...]
typedef struct AVAttachmentButton { uint16_t x; uint16_t y; uint16_t w; uint16_t h; } AVAttachmentButton;
64k should be enough for everyone ;) i do prefer int for this and most other variables
typedef struct AVDVDParseContext { // pts of this context int64_t pts;
// type uint16_t Type;
// when waiting uint16_t Wait;
// when buttons uint16_t HighLightIndex; uint16_t ButtonCount; AVAttachmentButton Buttons[MAX_ATTACH_BUTTONS];
// when color-palette uint32_t rgba_palette[16];
seems like job for a union not a struct
// expected size of the video pictures (allows for skip of scan-stream) uint16_t video_width; uint16_t video_height;
// aspect ratio (0 = 4:3 , 3 = 16:9) uint8_t aspect_ratio : 4; // video format (0 = ntsc, 1 = pal) uint8_t video_format : 4;
// current vts uint8_t current_vts;
// count of languages uint8_t AudioLanguage_Count; uint8_t SubTitleLanguage_Count;
// languages uint16_t Audio_Language[MAX_ATTACH_AUDIO_LANGUAGE]; uint16_t Audio_Flags[MAX_ATTACH_AUDIO_LANGUAGE]; uint8_t Audio_Channels[MAX_ATTACH_AUDIO_LANGUAGE]; uint8_t Audio_Mode[MAX_ATTACH_AUDIO_LANGUAGE]; uint16_t SubTitle_Language[MAX_ATTACH_SUB_LANGUAGE]; uint16_t SubTitle_Flags[MAX_ATTACH_SUB_LANGUAGE];
alot of this looks misplaced, width, height, aspect and language have their fields in AVStream & AVCodecContext already. So please explain why they are here duplicated.
// when angle change uint8_t current_angle; uint8_t max_angle;
// size of current title in pts ticks. divide by 90000 to get time in seconds uint64_t titletime;
needs a AVRational time_base instead of 90khz and i guess duration is a better term
// flags that describe actions allowed for current chapter uint32_t flags;
} AVDVDParseContext;
Also this name hurt my eyes, this could be usefull for MMS/RTP and who knows what else. In that sense it also should be kept reasonably generic
/* *************** protos *************** */
/* register */ int dvd_protocol_register(); /* select a button */ void dvd_protocol_select_button(AVFormatContext *ctx, uint32_t nIndex); /* signal queue empty */ void dvd_protocol_signal_wait(AVFormatContext *ctx, uint32_t iSkip); /* signal queue empty */ void dvd_protocol_signal_queue(AVFormatContext *ctx); /* reset has been processed */ void dvd_protocol_signal_reset(AVFormatContext *ctx);
A more generic message passing to AVProtocols seems better than one function specific to one protocol and function each [...]
@@ -2493,10 +2544,10 @@ av_log(s, AV_LOG_ERROR, "dimensions not set\n"); return -1; } - if(av_cmp_q(st->sample_aspect_ratio, st->codec->sample_aspect_ratio)){ - av_log(s, AV_LOG_ERROR, "Aspect ratio mismatch between encoder and muxer layer\n"); - return -1; - } +// if(av_cmp_q(st->sample_aspect_ratio, st->codec->sample_aspect_ratio)){ +// av_log(s, AV_LOG_ERROR, "Aspect ratio mismatch between encoder and muxer layer\n"); +// return -1; + // } break; }
@@ -2932,6 +2983,7 @@ } #endif
+/* @@@ BUG BUG will fail on encoding at t 23.59.59 started + */ int64_t av_gettime(void) { struct timeval tv;
ehm ... [...]
Index: avformat.h =================================================================== --- avformat.h (revision 19309) +++ avformat.h (working copy) @@ -185,6 +185,7 @@ #define AVFMT_GENERIC_INDEX 0x0100 /**< Use generic index building code. */ #define AVFMT_TS_DISCONT 0x0200 /**< Format allows timestamp discontinuities. */ #define AVFMT_VARIABLE_FPS 0x0400 /**< Format allows variable fps. */ +#define AVFMT_NOHEADER 0x0800 /**< do not try to read headers. */
what is this good for? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
Hi, quick cleanup of the work of Erik Van Grunderbeeck, burns and crashes but at still it allows to play a few seconds of a DVD with the command: ffplay dvd:///MOVIE I won't have much time for it, so feel free to pick it and get it in shape ;). -- FFmpeg = Faithful and Faithless Multimedia Practical Experimenting Geek
I see the follow -up on patches still takes time, I see I submitted this one 3 years ago :) There's a number of other changes that need to happen on this patch. I haven't worked on it for quite some time, but could if there's interest (and I find the time) I did a quick read on the list archive on responses. In general: 1) Yes, pts/dts can change and jump anywhere in a vob. It doesn't need to start from 0 neither, and interleaved angle changes (and alternative scenes) mean that you have to use the IFO file to read a DVD. Libdvd handles that. 2) The code in ffplay/ffmpeg needs to handle new streams being found (and possibly decoded). Example: subtitles in DVD often start several seconds/minutes into the movie, and if not found by the dedect routines will now never decode. Same with audio. 3) In general, find_stream_info needs to be turned to a 0 buffer. Otherwise resyncing with libdvd becomes a major headache. 4) Stream resets need to be handled. Vob files often concatenate several audio formats (aac 2 channel jumping to aac 5 channel for example), usually in the preview section of a DVD (the "preview" features on most DVD's). Some with video (going from ntsc <-> pal and back) 5) a/v sync needs to be more robust. Usually because audio can be delayed several packets in a vob file. 6) Things need to be signaled back to the dvd : wait and delay modes, menu selections, etc. libdvd handles this, but the app needs to tell it with to do. 7) Streams need to be able to be cleared (or deleted/reset) when a new vob/movie part is encountered. If someone wants to work on part of this, I can do some (or advise on how) of it, but I don't have loads of times anymore these days. E. -----Original Message----- From: Stefano Sabatini [mailto:stefasab@gmail.com] Sent: Sunday, January 22, 2012 5:53 PM To: ffmpeg-devel Mailing List Cc: Erik Van Grunderbeeck Subject: [WIP] DVD reader protocol Hi, quick cleanup of the work of Erik Van Grunderbeeck, burns and crashes but at still it allows to play a few seconds of a DVD with the command: ffplay dvd:///MOVIE I won't have much time for it, so feel free to pick it and get it in shape ;). -- FFmpeg = Faithful and Faithless Multimedia Practical Experimenting Geek
In data Monday 2012-01-23 12:20:49 +0100, Erik Van Grunderbeeck ha scritto:
I see the follow -up on patches still takes time, I see I submitted this one 3 years ago :)
Great to find you still around :).
There's a number of other changes that need to happen on this patch. I haven't worked on it for quite some time, but could if there's interest (and I find the time)
I did a quick read on the list archive on responses. In general:
1) Yes, pts/dts can change and jump anywhere in a vob. It doesn't need to start from 0 neither, and interleaved angle changes (and alternative scenes) mean that you have to use the IFO file to read a DVD. Libdvd handles that.
2) The code in ffplay/ffmpeg needs to handle new streams being found (and possibly decoded). Example: subtitles in DVD often start several seconds/minutes into the movie, and if not found by the dedect routines will now never decode. Same with audio.
3) In general, find_stream_info needs to be turned to a 0 buffer. Otherwise resyncing with libdvd becomes a major headache.
4) Stream resets need to be handled. Vob files often concatenate several audio formats (aac 2 channel jumping to aac 5 channel for example), usually in the preview section of a DVD (the "preview" features on most DVD's). Some with video (going from ntsc <-> pal and back)
5) a/v sync needs to be more robust. Usually because audio can be delayed several packets in a vob file.
6) Things need to be signaled back to the dvd : wait and delay modes, menu selections, etc. libdvd handles this, but the app needs to tell it with to do.
7) Streams need to be able to be cleared (or deleted/reset) when a new vob/movie part is encountered.
If someone wants to work on part of this, I can do some (or advise on how) of it, but I don't have loads of times anymore these days.
That would be highly appreciated, first of all I'd ask you to comment on your framework patches which I'm reattaching for convenience (and which clearly need to be cleaned up and rebased against the latest codebase), togheter with the dvdproto patch with a few more fixes (mostly cosmetics). Current patch alone allows to play the first chapter in the DVD, then ffplay starts to suck all system memory so I need to kill it. Thanks.
On Mon, Jan 23, 2012 at 10:48:22PM +0100, Stefano Sabatini wrote:
In data Monday 2012-01-23 12:20:49 +0100, Erik Van Grunderbeeck ha scritto:
I see the follow -up on patches still takes time, I see I submitted this one 3 years ago :)
Great to find you still around :).
There's a number of other changes that need to happen on this patch. I haven't worked on it for quite some time, but could if there's interest (and I find the time)
I did a quick read on the list archive on responses. In general:
1) Yes, pts/dts can change and jump anywhere in a vob. It doesn't need to start from 0 neither, and interleaved angle changes (and alternative scenes) mean that you have to use the IFO file to read a DVD. Libdvd handles that.
2) The code in ffplay/ffmpeg needs to handle new streams being found (and possibly decoded). Example: subtitles in DVD often start several seconds/minutes into the movie, and if not found by the dedect routines will now never decode. Same with audio.
3) In general, find_stream_info needs to be turned to a 0 buffer. Otherwise resyncing with libdvd becomes a major headache.
4) Stream resets need to be handled. Vob files often concatenate several audio formats (aac 2 channel jumping to aac 5 channel for example), usually in the preview section of a DVD (the "preview" features on most DVD's). Some with video (going from ntsc <-> pal and back)
5) a/v sync needs to be more robust. Usually because audio can be delayed several packets in a vob file.
6) Things need to be signaled back to the dvd : wait and delay modes, menu selections, etc. libdvd handles this, but the app needs to tell it with to do.
7) Streams need to be able to be cleared (or deleted/reset) when a new vob/movie part is encountered.
If someone wants to work on part of this, I can do some (or advise on how) of it, but I don't have loads of times anymore these days.
That would be highly appreciated, first of all I'd ask you to comment on your framework patches which I'm reattaching for convenience (and which clearly need to be cleaned up and rebased against the latest codebase), togheter with the dvdproto patch with a few more fixes (mostly cosmetics).
Current patch alone allows to play the first chapter in the DVD, then ffplay starts to suck all system memory so I need to kill it.
once either of you has a git branch that has this stuff working and in good shape. tell me and ill merge it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
On date Monday 2012-01-23 12:20:49 +0100, Erik Van Grunderbeeck encoded:
I see the follow -up on patches still takes time, I see I submitted this one 3 years ago :)
There's a number of other changes that need to happen on this patch. I haven't worked on it for quite some time, but could if there's interest (and I find the time)
I did a quick read on the list archive on responses. In general:
1) Yes, pts/dts can change and jump anywhere in a vob. It doesn't need to start from 0 neither, and interleaved angle changes (and alternative scenes) mean that you have to use the IFO file to read a DVD. Libdvd handles that.
2) The code in ffplay/ffmpeg needs to handle new streams being found (and possibly decoded). Example: subtitles in DVD often start several seconds/minutes into the movie, and if not found by the dedect routines will now never decode. Same with audio.
3) In general, find_stream_info needs to be turned to a 0 buffer. Otherwise resyncing with libdvd becomes a major headache.
4) Stream resets need to be handled. Vob files often concatenate several audio formats (aac 2 channel jumping to aac 5 channel for example), usually in the preview section of a DVD (the "preview" features on most DVD's). Some with video (going from ntsc <-> pal and back)
5) a/v sync needs to be more robust. Usually because audio can be delayed several packets in a vob file.
6) Things need to be signaled back to the dvd : wait and delay modes, menu selections, etc. libdvd handles this, but the app needs to tell it with to do.
7) Streams need to be able to be cleared (or deleted/reset) when a new vob/movie part is encountered.
If someone wants to work on part of this, I can do some (or advise on how) of it, but I don't have loads of times anymore these days.
Before to jump at finetuning I want to get simple playback (even if clunky) working. Your patchset was old and incomplete and I had to figure out how to put all the pieces togheter, so something is not yet working properly. Now my main problem is that I don't know how I am supposed to deal with a sector/VOBU end, dvd_read() keeps reading from dvdnav_get_next_block(), at some point I get "Truncating packet" ffio_limit() errors when I reach the end of the AVIOContext buffer (which is the size of the VOBU). I suppose I need a mechanism for automatically skipping to the next chapter/VOBU when a certain VOBU end is reached (how to test it?), but I'm not sure about which is the best method for doing that. -- FFmpeg = Fancy and Foolish Mystic Pure Enhancing Gladiator
If someone wants to work on part of this, I can do some (or advise on how) of it, but I don't have loads of times anymore these days.
Before to jump at finetuning I want to get simple playback (even if clunky) working. Your patchset was old and incomplete and I had to figure out how to put all the pieces togheter, so something is not yet working properly.
Now my main problem is that I don't know how I am supposed to deal with a sector/VOBU end, dvd_read() keeps reading from dvdnav_get_next_block(), at some point I get "Truncating packet" ffio_limit() errors when I reach the end of the AVIOContext buffer (which is the size of the VOBU).
I suppose I need a mechanism for automatically skipping to the next chapter/VOBU when a certain VOBU end is reached (how to test it?), but I'm not sure about which is the best method for doing that.
Yes. VOBU skipping in a chapter should be automatic, since they will be handled by the IFO data structures. When a chapter ends, libdvd will send a message to the callback stating with the next transition state in the FSM of the DVD is. Its up to the player to respond to that. This can be several messages: DVDNAV_WAIT, DVDNAV_VTS_CHANGE:, etc. Depending on these, actions need to be taken. I send these messages on a seperate callback that has a timestamp of the event, and a structure containing extracted message data. Why a seperate callback and not inject them in the stream? Mainly because of the buffering of the FFMpeg libraries. Inserting non-stream dynamic packages leads to several problems there. For the scenario above, the VTS change messages are the most important. Note that however, almost every DVD package creator reads the spec differently. Eg. sometimes a set of messages will be included, sometimes a domain change will be there, ... E. -- FFmpeg = Fancy and Foolish Mystic Pure Enhancing Gladiator
7) Streams need to be able to be cleared (or deleted/reset) when a new vob/movie part is encountered.
This btw is another issue you will hit with chapter/vobu changes: a new vobu can introduce new streams (well, chapters will introduce them, but the are generated by opening vobu's). More often then not these streams in the "new" vobu will be mpeg streams with the same mpeg stream id's as the stream's in the "old" vobu. Almost certain with video streams. Since these new streams are very likely to have different settings, you at least need to flush all internal cashes (the reference id's for the pictures for example). The way I had it in the patch was to mark these streams as invalid, and then on a av_new_stream() do a smart select, deleting them. This allows the stream to be at the front-end as long as possible, helping decoder caching of frames (which, in bluray decoding becomes rather important later (with a bluray lib)). All in all, the unfortunate news is that its very hard to just do an initial "get it working" implementation. You sort-of need the whole framework. E.
Hi Erik, On Monday, 23 January 2012 at 12:20, Erik Van Grunderbeeck wrote:
I see the follow -up on patches still takes time, I see I submitted this one 3 years ago :)
If you have any changes to libdvdread/libdvdnav, please post them to the dvdnav-discuss mailing list and Cc: me. I'll try to get them committed. Regards, Dominik -- MPlayer http://mplayerhq.hu | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
participants (6)
-
Dominik 'Rathann' Mierzejewski -
Erik Van Grunderbeeck -
erik＠arawix.com
-
Michael Niedermayer -
michaelni＠gmx.at
-
Stefano Sabatini