Difference between revisions of "SoC 2010 Ogg Demuxer"
m |
|||
Line 5: | Line 5: | ||
I started by porting and adapting the existing code from the LiVES ogg/theora decoder. | I started by porting and adapting the existing code from the LiVES ogg/theora decoder. | ||
− | I made some updates to ogg.c and added the new files oggseek.c and oggseek.h. Some definitions from ogg.c were moved into the new file ogg.h since they are now common to both ogg.c and oggseek.c | + | I made some updates to [http://lives.sourceforge.net/other_projects/vlc/ogg.c ogg.c] and added the new files [http://lives.sourceforge.net/other_projects/vlc/oggseek.c oggseek.c] and [http://lives.sourceforge.net/other_projects/vlc/oggseek.h oggseek.h]. Some definitions from ogg.c were moved into the new file [http://lives.sourceforge.net/other_projects/vlc/ogg.h ogg.h] since they are now common to both ogg.c and oggseek.c. I also updated [http://lives.sourceforge.net/other_projects/vlc/Modules.am Modules.am] with the new files. |
As a first test, I was able to correctly determine the total number of frames in various ogg/theora files: | As a first test, I was able to correctly determine the total number of frames in various ogg/theora files: | ||
Line 26: | Line 26: | ||
This can be uncomfortable for the user because it could require a pre-roll of quite a few frames, so you can see the time slider moving at the bottom but there is no video or audio playing until the pre-roll catches up. What I would like to know, is there a way to tell the player "give me the next packet as quick as possible" ? Then it would zip through the pre-roll quickly and the user would not notice anything. I have emailed my mentor to ask this (since the player code is done outside of the demuxer). | This can be uncomfortable for the user because it could require a pre-roll of quite a few frames, so you can see the time slider moving at the bottom but there is no video or audio playing until the pre-roll catches up. What I would like to know, is there a way to tell the player "give me the next packet as quick as possible" ? Then it would zip through the pre-roll quickly and the user would not notice anything. I have emailed my mentor to ask this (since the player code is done outside of the demuxer). | ||
− | Implementing pre-roll for theora meant a minor change to the theora.c codec file. This change should not impact any of the other demuxers. | + | Implementing pre-roll for theora meant a minor change to the [http://lives.sourceforge.net/other_projects/vlc/theora.c theora.c] codec file. This change should not impact any of the other demuxers. |
Revision as of 15:42, 27 May 2010
Week 1:
26th May 2010
I started by porting and adapting the existing code from the LiVES ogg/theora decoder.
I made some updates to ogg.c and added the new files oggseek.c and oggseek.h. Some definitions from ogg.c were moved into the new file ogg.h since they are now common to both ogg.c and oggseek.c. I also updated Modules.am with the new files.
As a first test, I was able to correctly determine the total number of frames in various ogg/theora files:
- seek to the last ogg page for a given stream (i.e. the theora stream) - get the granulepos - convert the granulepos to a frame number - set the total number of frames
As a result the demuxer can now return the file length in microseconds. This can be seen in the interface at the bottom. Previously this figure was an estimate, but now it is accurate.
As a second test, I was able to seek roughly to any given frame or time in a clip. Right now it is not frame accurate, so there are still some minor artifacts after seeking. I plan to fix this properly in the next couple of days.
One thing which was slightly unexpected - vlc may (?) start playback before all of the stream header data is read. This means that when getting the frame count, for very small files we may read back into the header data. I need to investigate if this is a problem or not - so far it has not caused any issues.
27th May 2010
Today I hit the first problem. In order to seek to an inter frame, we need to rewind to the previous intra frame and the pre-roll to the target. However, when vlc does a pre-roll it does so at the normal frame rate. This can be uncomfortable for the user because it could require a pre-roll of quite a few frames, so you can see the time slider moving at the bottom but there is no video or audio playing until the pre-roll catches up. What I would like to know, is there a way to tell the player "give me the next packet as quick as possible" ? Then it would zip through the pre-roll quickly and the user would not notice anything. I have emailed my mentor to ask this (since the player code is done outside of the demuxer).
Implementing pre-roll for theora meant a minor change to the theora.c codec file. This change should not impact any of the other demuxers.
TODO:
This week:
- seek to the exact frame required (i.e skip frames until we hit the target frame) - done (but see above)
- work out how to tell if we are dealing with a remote stream (which has no seek capabilities)
- check audio and subtitle sync after a seek
- test with more ogg/theora clips (including very small clips, see above)
- clean up the code (mostly done)
- see if we can pull/use more meta data from the stream (e.g. comments, codec version, aspect ratio, frame and picture size, x and y offsets)
Week 2:
I plan to backport the updated code back in to LiVES, since I made a few corrections and improvements to the code. Split the LiVES code into demuxer/decoder - this will be necessary for the next part.
Week 3:
Investigate how seeking works with dirac video streams (it is slightly different to theora in that there is a lower bound, but no upper bound). Test implementation of this in LiVES first.
Week 4:
Continue work from week 3, and begin porting dirac code from LiVES to vlc.
Week 5+:
TBD. (Maybe look at x and y offsets, maybe look at multiple clips within one ogg container, possibly add ogg skeleton support).
Frei0r effects ?
Jack audio output ?
Port other demuxers/decoders to LiVES ?
Note:
I will be mostly unavailable after 29th July (attending Piksel Summer Camp and then family commitments), but I should have all of the coding for the main project done well before that.