[FFmpeg-devel] Added support for XV video files

Michael Niedermayer michael at niedermayer.cc
Tue Mar 26 14:50:33 EET 2019


On Mon, Mar 25, 2019 at 04:19:37PM +0530, Shivam Goyal wrote:
> 
> On 3/25/19 3:59 PM, Michael Niedermayer wrote:
> >On Sun, Mar 24, 2019 at 04:35:40PM +0530, Shivam Goyal wrote:
> >>The attached patch is for ticket #3720
> >>
> >>     https://trac.ffmpeg.org/ticket/3720
> >>
> >>I have tested this demuxer on the files 1.xv and 5.xv attached with the
> >>ticket
> >>
> >>http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3720/
> >>
> >>
> >>  It is working on both of these files.
> >>
> >>As XV video files are flv files with some encrypted data. These can be
> >>converted to flv without loosing video quality (and it would be really
> >>fast). I have also tried this and it is working "ffmpeg -i 1.xv -c copy
> >>converted.flv".
> >>
> >>
> >>Please suggest any improvements
> >>
> >>
> >[...]
> >
> >>diff --git a/libavformat/xvtools.h b/libavformat/xvtools.h
> >>new file mode 100644
> >>index 0000000000..42c2c65c46
> >>--- /dev/null
> >>+++ b/libavformat/xvtools.h
> >>@@ -0,0 +1,95 @@
> >>+int flvid = 0x46;
> >>+
> >>+
> >>+int byte_shift(int byte,int shift);
> >>+int find_rot(AVIOContext *pb);
> >>+int xvio_r8(AVIOContext *pb, int rot);
> >>+unsigned int xvio_rb16(AVIOContext *s, int rot);
> >>+unsigned int xvio_rb24(AVIOContext *s, int rot);
> >>+unsigned int xvio_rb32(AVIOContext *s, int rot);
> >>+uint64_t xvio_rb64(AVIOContext *s, int rot);
> >>+int xv_string_decrypt(int64_t curr_pos, char *buffer, int length, int rot);
> >>+
> >>+
> >>+
> >>+int byte_shift(int byte,int shift){
> >>+    return ((byte + shift)&0xff);
> >>+}
> >>+
> >>+
> >>+int find_rot(AVIOContext *pb){
> >>+    int64_t curr_pos = avio_tell(pb);
> >>+    avio_seek(pb,0x200000,SEEK_SET);
> >>+    int rot = flvid - avio_r8(pb);
> >>+    avio_seek(pb,curr_pos, SEEK_SET);
> >>+    return rot;
> >>+}
> >>+
> >>+
> >>+
> >>+int xvio_r8(AVIOContext *pb, int rot){
> >>+    int64_t curr_pos = avio_tell(pb);
> >>+    if(curr_pos < 0x200400){
> >>+        int ret=avio_r8(pb);
> >>+        if(ret == 0)return 0;
> >>+        ret = byte_shift(ret,rot);
> >>+        return ret;
> >>+    }
> >>+    int ret=avio_r8(pb);
> >>+    return ret;
> >>+}
> >There is so much wrong with this code
> >global variables are not ok in a demuxer that can have multiple instances
> >global variables do not belong in headers either
> >also non static inline functions do not belong in headers
> >
> >this xvio stuff all looks like a bad idea.
> >Do i guess correctly that this fileformat is flv but scrambled at the IO
> >layer ?
> >if this is true it may be possible to implement a xv demuxer as a
> >descrambler which than passes the data on to a unchanged flv demuxer.
> >If that how this xv fundamentally works then that would be much
> >cleaner.
> >Also theflv demuxer duplication is not ok
> 
> Yeah The XV file is a flv file which starts from 0x200000 byte and its
> _next__0x400_ bytes are encrypted by something like caesar cipher (the bytes
> after 0x200400 till the end of the file are not encrypted) . So, Please
> suggest what would be best solution for this situation and how can i change
> this.

look at the KUX format patch

for the IO stuff, there are 2 obvious ways
1. if this is limited to the only once read header, it should be possible
to just allocate an array, read the bytes for the header decrypt it create
a avio context on it and pass this to the header decode code. This also
assumes that the size is limited and never too large
2. if this is not limited to the once read header but can extend into the
flv frames, a avio context can be created that passes its read calls on to
the parent and decrypts as needed. so there are always 2 avio contexts and 
the flv demuxer code would see "virtual" data that has been decrypted

there are many other ways. You can probably as the one working on this
better decide as ou work on it what path makes sense. But please try to
keep the implementation cleaner than the initial patch was

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190326/2056a236/attachment.sig>


More information about the ffmpeg-devel mailing list