Re: Enhanced Podcasts with Ogg Vorbis (Chapter Marks)

Hallo!

Am 2012-04-10 06:56, schrieb Silvia Pfeiffer:
> OK, let's do it. I'm the last one who wants to stand in the way of
> introducing URLs into media content! :-)
>
> Let's definitely introduce a URL field on chapters:
> CHAPTERxxxURL=http://

That's great ;)
Should it also be allowed to have multiple URLs per chapter?
(Just by using the same CHAPTERxxxURL key multiple times)


> But what should we do about images? Surely they should be embedded
> into the file and not just be a url?

Yes ... but, I am also not sure about images ...

>
> Thus, this would work:
> CHAPTERxxxBLOCKPICTURE=blahblah
>
> Also, the HindenburgSystem demo that you pointed to showed that you
> can select different subparts of an image for display.  How do you want
> to accommodate that? It seems that Apple only supports 300x300 images
> (see http://blog.makezine.com/2008/02/29/how-to-make-enhanced-podc/).
> Do we have to transcode the images before base64 encoding them and
> embedding them into VorbisComment?

Hm, I don't know if this restriction is usefull in VorbisComments ...
Wouldn't it be easier to just embed any images?
Then the client is responsible to set a specific resolution or just take 
a subpart of an image.

BTW: here is also some code on how to add images in MP4 (see 
write_chapterimagesToFile()):
https://github.com/kyrios/atomatic/blob/master/lib/MP4.py

> Does anybody know when we hit the limit of VorbisComment size that
> makes HW players cry?

For me that's the important question ...


Thanks for your answer!
LG
Georg

>
> Cheers,
> Silvia.
>
>
> On Mon, Apr 2, 2012 at 10:31 PM, Georg Holzmann<[email protected]>  wrote:
>> Hallo Sivlia, Martin!
>>
>>
>>> Somebody (perhaps Georg) suggested this a
>>> few weeks ago at:
>>> https://wiki.xiph.org/Talk:Chapter_Extension
>>
>> No, this wasn't me - but nice to see that others are interested too ... ;)
>>
>>
>>> I think that would turn chapters into a really confused content track.
>>> Think about it: chapters are there to provide navigation pointers to
>>> people that come to the video. Now you're attaching outgoing pointers
>>> to the incoming anchors. That's a very separate type of content and
>>> requires rendering of the outgoing pointers and enable user
>>> interaction. In particular if you want to enable more than one
>>> hyperlink, how is that supposed to be rendered?
>>
>>
>> We just get this feature request and are implementing this ATM for MP4 and
>> MP3 audio - and thought it would be nice to have in Vorbis too ...
>> In MP4 you have a separate track, in MP3 (ID3) this is directly attached to
>> the chapters [1].
>>
>> Podcast authoring software, like Hindeburg (see [2] how they create
>> chapters) or I thing also Garageband, allows you to set a link and a picture
>> for a chapter, and clients also display them (e.g. players on the
>> "i-devices" or the popular instacast [3]).
>>
>>
>>> Instead, I would suggest to create actual content tracks, i.e. tracks
>>> that have text or markup in them and have been built to be displayed.
>>> The way that we recommend doing this are Kate tracks. You can author
>>> them as SRT or KATE files (hopefully we will also support WebVTT at
>>> some stage). You would author cues that align with your chapter
>>> markers if necessary, but they don't have to, because the content will
>>> be active as you're watching the video. This is in comparison to
>>> chapter markers which are visible *before* you start watching the
>>> video.
>>
>>
>> Yes, that would be the other possibility.
>>
>> However, do you know if (hardware) player have problems with ogg audio files
>> with kate tracks?
>> Because it would be quite trivial to add them in the VorbisComment header
>> ...
>>
>>
>>
>>>> Yes, and the final thing would be images for chapters ;) (or at some
>>>> timepoints)
>>>
>>>
>>> So, this is another issue altogether. If you want chapters displayed
>>> for navigation purposes, but augmented with sample frames for the
>>> chapters to give a visual indication of what one may jump into when
>>> going to the chapter, then we have to add these representative images
>>> to the chapters. Typically, they would be frames taken from the video.
>>
>>
>> Note: I am speaking about audio only files (although that might be useful
>> for videos as well).
>> In enhanced podcasts these images are displayed when you play the file.
>>
>>
>>> Alternatively, that could be a base64 encoded image and inlined,
>>> similar to how cover art can currently be included in VORBISCOMMENT
>>> [1]. Maybe a field name of CHAPTER001BLOCKPICTURE for this?
>>
>>
>> Yes, I also thought about this way ...
>> However, AFAIK there are problem with some hardware players if the
>> vorbiscomment header gets too big?
>> And if you have multiple images, the header will be very big ...
>>
>>
>>> OggSpots is not for this purpose - it was suggested as a low bandwidth
>>> "video" codec that just shows still images at certain times, but never
>>> got implemented.
>>> OggKate is for caption, karaoke and similar text tracks. You could put
>>> hyperlinks into OggKate, but I believe it would just be rendered as
>>> text by those players that understand OggKate. So, I'm not sure it
>>> will solve your problem.
>>
>>
>> OK, thanks. I thought images are also possible with OggKate as noted here:
>> http://wiki.xiph.org/OggKate#Images
>>
>>
>> Thanks for the answers!
>> LG
>> Georg
>>
>>
>> [1]: http://www.id3.org/id3v2-chapters-1.0
>> [2]: see this video on how to create chapters with links and images with
>> hindeburg:
>> http://www.youtube.com/watch?v=Ago1_7aLYQY&feature=plcp&context=C4f45b8eVDvjVQa1PpcFP7RTwouNwgPPcMIyFDSz86-Fh1LfinAw8%3D
>> [3]: http://vemedio.com/products/instacast
>>
>>
>> --
>> auphonic - automatic audio post production
>> http://auphonic.com
>> audio development, machine learning, open source and more


-- 
auphonic - automatic audio post production
http://auphonic.com
audio development, machine learning, open source and more